0

I'm following a git branching model with two long running branches (dev, master) and where feature branches are based from master mostly (or dev sometimes) and merged to dev and then dev is merged to master after few features (all merges are no-ff merges).

git checkout -b feature master
// work
git checkout dev
git merge --no-ff feature
// after n features
git checkout master
git merge --no-ff dev

Now after 5 merges of dev to master

git rev-list --left-only --count master...dev
5

gives an impression that there are changes in master that are not in dev.

I have been solving this by ff-ing dev after merging dev to master. Branches in flight will be based on what dev was before the ff merge to master (391355d below instead of ca386a7). Is there a better way than this?

*   ca386a7 - Sun 05-Aug-2018 11:00 (6 days ago) (HEAD -> dev, master)
|\    Merge branch 'dev' - hIpPy
| *   391355d - Sun 05-Aug-2018 10:50 (6 days ago)
| |\    Merge branch 'cutg' into dev - hIpPy
| | * 53ca791 - Sun 05-Aug-2018 10:42 (6 days ago)
| |/    cutg: Teach to exclude binary files - hIpPy
|/|   
| *   269e4c7 - Sat 04-Aug-2018 13:14 (7 days ago)
| |\    Merge branch 'while-loop' into dev - hIpPy
| | * 356f50d - Sat 04-Aug-2018 13:01 (7 days ago)
| |/    while-loop: Fix bash while loop - hIpPy
| *   56a121a - Sat 04-Aug-2018 00:20 (8 days ago)
| |\    Merge branch 'pipe' into dev - hIpPy
hIpPy
  • 4,649
  • 6
  • 51
  • 65
  • 1
    Well if they are not `ff` commits, they are not "empty". There really is no concept of an empty commit. There are commits that are not in `dev`, plain as that. Sounds like this might be an [xy](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) - try and ask about you actually want of your tree, to help clarify. – kabanus Aug 12 '18 at 06:47
  • kabanus, Updated question. I meant a no-ff merge commit. – hIpPy Aug 12 '18 at 15:48
  • That was what I was referring to. You are force creating these commits. They really exist in master, and not in dev. It's not an impression. – kabanus Aug 12 '18 at 16:06
  • kabanus, what I mean is that it gives a false impression that there are changes in master that are not on dev. If a hotfix that is made on maint and merged to master but was forgotten to be merged to dev (maint is branched from master and merged to master and dev), `git rev-list --left-only --count master...dev` correctly shows that there are some commits (i.e. changes) on master that are not on dev. I'm doing no-ff merges for rollbacks (reverts). I hope that makes it clear. – hIpPy Aug 12 '18 at 20:47

0 Answers0