1

We recently migrated from SVN -> Git (using Stash) . After the migration , we have started seeing issues during merge where some developers are messing up the merge on their feature branch. 

**Our workflow model:-**

master    1---2----3------------4----5
            | |        |   |    |    | 
            | |        M   |    |    |  
feature1    | a--------b---     |    | 
            |                   M    |
feature2    c-----------------d-------

In the above figure lets say developer1 has a feature branch feature1 , has done his changes and merged back to develop.

Developer2 has a branch that was created before developer1's branch but is going to be around for a longer time. Once the changes are done, he pulls in changes from master into his branch , resolves any conflicts and then merges back in.

The problem is that when developer2 merges changes into his local branch he is resolving merge conflicts by preferring his own files. However, this is actually overriding some of the files that he has not changed . When he creates a pull request and merges back to master, he effectively rolls back the changes of developer1 to the previous version. We can fire this out because the file actually rolls back to the previous commit (SHA) id

The question is,

  1. is there a way we can avoid this systematically i.e ask git to reject any changes into master where the change SHA id is actually a rollback.
  2. Is there a way during the merge when developers get conflicts only on the files that they have changed

My googling brought me to articles which suggested doing a git pull with the --rebase option or changing the permission on master branch so that they will only allow fast-forward merges. Will either of the options helps.

Biswajit_86
  • 3,661
  • 2
  • 22
  • 36
  • Tell you developers to stop using `--ours` or similar flags and to actually merge changes instead of just blowing them away. To require fast-forward merges requires that the feature branches are rebased before being merged (which will still require merging and can still be messed up). – Etan Reisner Aug 17 '14 at 22:53
  • 3
    if your developers don't understand merging, they will absolutely not understand rebasing and will cause far worse damage. don't even **mention** rebase. – Eevee Aug 17 '14 at 23:20
  • No oe uses --ours or similar flags while merging. The problemn that we have is we have mainly 3 tools for using git. Many people use tortoise git, Many others use git bash and a few others use eclipse/intellij ides to do their git work. – Biswajit_86 Aug 17 '14 at 23:20
  • so, i'm confused. (a) how are developers managing to roll back files they didn't touch in the first place? (b) what do you mean, "the file rolls back to the previous commit id"? (c) why is the pull request approved if it screws up master? – Eevee Aug 17 '14 at 23:21
  • (a) developers are not technically rolling back files. When presented with merge conflicts , they are sometimes selecting their version over the remote version. (c)This should be caught in pull request but there are times when we have changes to more than 50-100 files and the reviewers are not making certain that all the 100 files are part of this change. Our pull request approvers are QA personnel who approve any pull request if it was tested succesfully(open to interpretation) – Biswajit_86 Aug 17 '14 at 23:26
  • @Eevee (b) When a pull request is created in git and the file that is part of the pull request is a previous version, Git does not add it as a commit. It smartly hides the last commit from the history. So for example if a file has sha ids a,b,c in the history and a new pull request adds commit b, after the request is approved, you will only see commit id a and b if you run a git log on the file – Biswajit_86 Aug 17 '14 at 23:28
  • (a) you said this happens with files your devs haven't changed, in which case git shouldn't even consider them conflicting. (c) uh, your reviewers should absolutely be _developers_. code review is worthless if it's not reviewed by people who _understand the code_. – Eevee Aug 17 '14 at 23:29
  • @Eevee, I agree on (c) but unfortunately I do not have any control or say in that process. Which is why I am trying to find out a process or a safe and reliable git command so that I can handle it before it goes to pull request – Biswajit_86 Aug 17 '14 at 23:32
  • there isn't one. this is precisely what pull requests _are for_. best you can do is lecture the developers who are doing this. – Eevee Aug 17 '14 at 23:35
  • 1
    Good test coverage and tests running in CI upon pull request will help, but there is no single silver bullet. – steveax Jun 11 '15 at 03:30

1 Answers1

-1

Welcome to git. this is where you realise it's not magic, merging issues haven't disappeared, and you still need to merge like you always did.

The answer is to ensure developers merge correctly, and no tool in the world will force you to do that. It's a people problem ultimately.

I would recommend code reviews that are mandatory for all push requests back to origin, or merging to master. One of the reviews will be to inspect the history to see if any such overrides has occurred with appropriate censures.

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
  • I totally agree and it is what I am trying to do. What I am looking for is a way to automatically inspect the history to check if any override has occurred. Some of our pull request have >100 files and it sometimes is difficult to manually inspect history of each file. – Biswajit_86 Aug 17 '14 at 23:35