I am confused about some concepts in Git.

I try to use GitHub for my codes.

I have a branch main and I treat it as my deployable branch.

Then, I create a dev branch from the main branch for my development.

My workflow is whenever there are new changes, I will add to dev and test it.

If everything is alright, I will merge it to 'main' for deployment.

So, I add some changes to dev and make a pull request merging it to main.

However, I notice the dev branch is 1 commit behind main after merging. I can see main contains one extra commit from the merge pull request.

My Questions:

Should I make dev branch always up to date regarding to main and why? If so, how can I do it?

CodePudding user response：

tl;dr: In your case, the extra commit is due to merging using --no-ff as evidenced by the "merge pull request" message, so you don't need to merge that commit back into dev.

Generally:

Whether you need to merge main back down into dev depends on why main is ahead of dev by some number of commits. As mentioned in Sıddık Açıl's comment, after the merge, if the two branches don't have any differences, meaning they differ by commits only, then you don't need to bring that commit from main back into dev. One way to differ in commits only is if you are using --no-ff when mergeing dev into main. That forces the creation of a merge commit even when one isn't necessary. Note if you are using --no-ff, then over time you will build up additional merge commits on main that aren't in dev, so next time you'll have 2 commits, then the time after you'll have 3 commits, etc. (Unless you delete dev and re-create it from main, or just reset it to main, after every deployment, in which case that number will never get higher than 1.)

However, immediately after the merge, if git diff origin/dev..origin/main does have differences, then there must be changes on main that were never merged into dev. In that case you probably should merge main back into dev to keep it up to date with those changes. That being said, the better time to do that would have been immediately after new commits went directly to main, because if you wait until afterward it's likely that you tested something different than you deployed. Note the first time you have a hotfix into main, you will bring all of those extra merge commits from the PRs back into dev along with it, and that's fine. Just don't be surprised when you see it! (This won't happen if you happen to reset dev to main right after deployments.)

To summarize some rules of thumb:

1. If you add changes directly to main, then merge main back into dev ASAP.
2. After merging dev into main, as long as the two branches diff is empty, it's OK to have extra commits on main.

Side Note: I like using --no-ff in this application so I can see all the Production deployments with a --first-parent view. Some people prefer to instead allow fast-forward merges and tag each production deployment, and then compare a tag with the previous tag to obtain the same information. (I actually use --no-ff and still tag). It comes down to personal taste.