1

I have a developer who keeps committing, and every time he does - it does a git merge branch onto branch commit; every time. Even with his own code.

Ie, my history looks like this almost all the time. Occassionally one of my 6 devs will merge branch onto branch; but for most part they just have commits. This one dev, always always has it.

  • Dev Merge branch onto branch
  • Dev Commit
  • Dev Merge branch onto Branch
  • Dev Commit
  • Other Commit
  • Me Commit
  • Other Commit
  • Me Commit
  • Me Commit
  • Dev Merge Branch onto Branch
  • Dev Commit
  • Dev Merge branch onto branch
  • Dev Comm

He was runnign 1.7; now 2.0

  • git commit
  • git pull
  • git push

? Any ideas?

Rest of us are fine in terminal (mac); GH win; GH win powershell, etc.

Its annoying because the garbage merges are creating a pain to be able to git revert.

Nick
  • 1,208
  • 11
  • 26

1 Answers1

1

Instruct the dev to make fresh commits only after he has done a pull.

git creates merge commits only if the local branch and the upstream branch diverge from a common point. So, while the rest of the devs seem to be following this (i.e., they do a git pull before making any commits), the dev in question makes local commits and then does a git pull, therefore having the branches already diverged. Hence git is forced to recursively merge the changes, causing a merge commit to come into picture.

The other way to avoid this completely is to do a git fetch coupled with a git rebase organization wide, so that the history is maintained almost linearly without any merge commits.

Community
  • 1
  • 1
Anshul Goyal
  • 73,278
  • 37
  • 149
  • 186
  • So git pull, work, git commit. Then push? Then git pull? or would he have o git pull, work, commit, fetch, rebase. – Nick Jul 17 '14 at 20:18
  • Either got pull, work, git commit, git push. Or work, commit, git fetch, git rebase, git push. In your case, first is easier to implement. – Anshul Goyal Jul 18 '14 at 04:11