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.

CodePudding user response：

Given this:

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

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 that master is a "good" branch. Instead you're treating develop 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 resetting develop periodically, and if you're the only user of the develop branch at the moment, then resetting after every PR into master makes sense. Regarding the issue of your pipeline breaking:

I could delete develop after each pull request and remake it but this makes an error in code pipeline

And clarified in your comment:

The error happens in pipeline because the branch has been deleted so the pipeline tries to run but fails with a message similar to branch not found.

The simple solution for this is to never actually delete the develop branch. Instead just reset it, perhaps like this:

git fetch
git switch develop
git reset --hard origin/master
git push --force

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 name develop is oftentimes associated with a workflow called Git Flow, and in that context the develop 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 into develop 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 of master with a relevant named feature branch (e.g. user/b2020/add-new-cool-thing or feature/add-new-cool-thing), and then merge it into master 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/* or user/*, etc.), but if you want to lock down to a specific branch name, I would suggest calling it next, 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 of master, but first merge them into next for testing before you complete your merge into master. Then periodically reset next 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 your develop branch to next, 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 rename master to main too if you wish.