I have a very basic scenario but I don't understand what is the correct way of handling it.
I have a Master Branch and a Develop Branch
Master does not receive commits directly, I make commits to develop which triggers an AWS code pipeline - these are tested approved and if ok I make a pull request
Pull request is Merged with Master (not sure if I am doing this right I use the rebase and merge option from github).
So far everything is good.
Now I want to continue doing some work so i make more commits to Develop and get ready to do a new Pull request. My problem is now it saying it will do all the commits since i originally made the Develop branch not just the ones since the Pull Request.
I could delete develop after each pull request and remake it but this makes an error in code pipeline, i'd rather just keep develop, and somehow get these inline.
I don't know what step is missing and I could really use some help, I tried looking for similar questions on here and on google but nothing really matched exactly.
If i have made a mistake on this one that's ok but moving forward i'd really appreciate knowing the correct steps to make this a smooth process.
If it matters at all i am using Github Desktop but if command line is needed that's fine.
Given this:
I'm going to start by focusing on the words: "these are tested approved and if ok..."
This suggests if the tests fail, that you will fixup
develop
and push out your changes to see if your fix attempt worked. Given this,develop
is not necessarily a "good" branch in the same way thatmaster
is a "good" branch. Instead you're treatingdevelop
kind of like a "feature" or "topic" branch that is a work-in-progress until you get it right. Given that, I like your suggestion of resettingdevelop
periodically, and if you're the only user of thedevelop
branch at the moment, then resetting after every PR intomaster
makes sense. Regarding the issue of your pipeline breaking:And clarified in your comment:
The simple solution for this is to never actually delete the
develop
branch. Instead just reset it, perhaps like this:In this way the branch will always exist and the pipeline won't complain about not being able to find the branch.
Branch name tip: Although branch names don't actually matter as long as you (and your team if you have one) understand exactly what they are and how they work, I would consider renaming your
develop
branch to something else. The branch namedevelop
is oftentimes associated with a workflow called Git Flow, and in that context thedevelop
branch lives forever and normally would never get reset. Typically testing would be done on feature branches until they are ready, and then they are merged intodevelop
with the goal of always having it be in a "good" state. The workflow you are currently using is more akin to GitHub Flow. In that flow you branch off ofmaster
with a relevant named feature branch (e.g.user/b2020/add-new-cool-thing
orfeature/add-new-cool-thing
), and then merge it intomaster
when you're done and delete that branch. Note you may have multiple feature branches going at once, especially if you add more team members. Most testing pipelines will enable you to test multiple branch names, (e.g.feature/*
oruser/*
, etc.), but if you want to lock down to a specific branch name, I would suggest calling itnext
, which is what the maintainers of Git call their short-lived test branch in gitworkflow. If you have multiple developers each of you would still make feature branches off ofmaster
, but first merge them intonext
for testing before you complete your merge intomaster
. Then periodically resetnext
whenever it makes sense. You could do it after every PR if you wish; at my company we currently do it every Monday morning. For now, if you like working on only one branch, consider renaming yourdevelop
branch tonext
, and you can commit to that directly until you have other team members, or until you decide to work on multiple features in parallel. And while you're renaming branches, you could renamemaster
tomain
too if you wish.