2

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?

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
ikhvjs
  • 5,316
  • 2
  • 13
  • 36
  • 1
    Does `git diff origin/dev..origin/main` return an empty result? – Sıddık Açıl Feb 18 '22 at 17:06
  • It might be worth a look at GitHub flow: https://docs.github.com/en/get-started/quickstart/github-flow for a simple branching strategy that would fit your model. Essentially you are doing that, but reusing an old branch (dev) instead of creating a new feature branch from main for new work. – Andrew McClement Feb 18 '22 at 18:31
  • @AndrewMcClement I agree the question basically describes GitHub Flow. And, I was about to point out my biggest issue with GitHub Flow (which was deploying from the feature branch), but I can't find that anymore. They must have recently gotten rid of that part of the flow! – TTT Feb 18 '22 at 18:47
  • @AndrewMcClement, Thanks for your suggestion. As I want to implement GitHub Action Testing for the `dev` branch, I don't want to delete it once it merged. – ikhvjs Feb 21 '22 at 11:28

1 Answers1

4

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.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • Thanks for your detailed answer and it turns out what I want is a fast-forward merge. Also, I am expecting the `GitHub web UI` to be defaulted as fast-forward merge but it does not. It provide 3 options but none of it is a fast-forward merge but you can still make a fast-forward merge with CLI which coexist with the protected branch option. – ikhvjs Feb 21 '22 at 10:14
  • @ikhvjs GitHub has a "rebase and fast-forward" merge option, but AFAIK there is no option for doing the regular Git default merge, which is "fast-forward if possible otherwise create a merge commit". Even from the CLI the [`-m` merge option](https://cli.github.com/manual/gh_pr_merge) still [uses `--no-ff`](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request). – TTT Feb 21 '22 at 14:55
  • @ikhvjs if new commits on `dev` are all linear, you *could* use "rebase and ff" option, but it's risky in general for long-lived branches because you'd have to confirm each time that you don't have new merge commits on `dev`. (And you'd pretty much have to reset `dev` afterwards.) I think the only way to get what you desire is to merge `dev` into `main` yourself locally, then give your user permission to bypass branch protection (or completely disable it) temporarily, push out `main`, then re-enable the protection. – TTT Feb 21 '22 at 15:08
  • 1
    After you created a pull request, you can still make a fast-forward merge with `CLI` like `git merge dev` which coexist with the GitHub protected branch option. I also tested it and it works. related answer: https://stackoverflow.com/a/66906599/14032355 – ikhvjs Feb 21 '22 at 15:14
  • @ikhvjs Are you saying, from the GitHub CLI, if you did `gh pr merge -m` it would create a merge commit, but if you do `git merge` it will use the default behavior, and it will still let you push that out when branch protection is on? – TTT Feb 21 '22 at 15:21
  • 1
    I am talking about normal shell script with git `git merge dev`. Yes, you can still push the branch when the branch protection is on, but you must create a pull request in the first place, otherwise it won't allow you to pass. – ikhvjs Feb 21 '22 at 15:23
  • @ikhvjs OK, good to know. I didn't know you could push to a protected branch like that in GitHub. I don't know that I'd setup my repo to allow that, but if all the checks are in place I guess it makes sense. I mostly use AzureDevOps and AFAIK that isn't a thing. I like that you can achieve what you want without messing around with permissions. In AzureDevOps AFAIK it's not even possible to do a fast-forward merge without potentially rebasing first. – TTT Feb 21 '22 at 15:26
  • Yes. I am happy it works but I do think GitHub should provide an option in the UI with fast-forward merge for people to choose. – ikhvjs Feb 21 '22 at 15:38
  • @ikhvjs I agree. Bitbucket has it and GitLab has a setting to only allow ff merges. It would be nice if GitHub and AzDO offered similar functionality. Kind of funny they don't offer the default Git merge strategy. ;) – TTT Feb 21 '22 at 15:47