1

We are using git and the merge workflow. We have lot of git newbies (including me) who either have an SVN or CVS background, or no version control background at all.

Here is a frequent issue we are running into. Many of the team members were using TortoiseGit. Merge conflicts happened fairly often because of concurrent changes - or since they did not pull every day. One user would do a pull, have a merge conflict, resolve the merge conflict, and then look at the list of files to be committed back.

But then the file list shows a lot of files, though there were merge conflicts involved in only a few files. While committing, he unchecked all the other files changes that he was not involved in, committed the results and pushed the commit.

Result: All the commits by other people that had been done between this user's previous commit and this one were lost!

First, why does Git or TortoiseGit just show a list of files that the user has nothing to do in the list? Second, what is the correct thing to do in this scenario - any answer from a TortoiseGit perspective will be helpful.

ring bearer
  • 20,383
  • 7
  • 59
  • 72
  • 2
    Rebase rebase rebase rebase rebase. – Josh Leitzel Nov 19 '13 at 17:08
  • 2
    @JoshLeitzel: In general, there are more opportunities for conflicts in a rebase workflow than a simple merge workflow. If developers don't understand how to use their conflict resolution tools appropriately then promoting rebase will tend to make things worse. – CB Bailey Nov 19 '13 at 17:18
  • 1
    @CharlesBailey If they don't understand them anyway, why not teach them the right way? And no, there are exactly the same conflicts -- you just have to deal with them in the appropriate place when you use rebase. – Josh Leitzel Nov 19 '13 at 17:25
  • 1
    @JoshLeitzel: Yes, they result in the same conflicts but with rebase the conflicts have to be resolved for each commit rebased. If the commits being rebased cover the same lines you can end up resolving very similar conflicts multiple times. You are right that tool education is the correct answer, I just didn't have enough words to make that an answer. "Rebase rebae rebase rebase rebase." is definitely not the answer, IMHO. – CB Bailey Nov 19 '13 at 17:43
  • @CharlesBailey probably why I posted it as a comment. – Josh Leitzel Nov 19 '13 at 17:55
  • @ringbearer did you ever figure this out? I can probably help you, but only from the perspective of using Git from the command-line. Also, what do you mean by "the merge workflow"? That is not an official description for any kind of current workflows using Git. For example, the two most popular workflows are "Git Flow" and "GitHub Flow". –  Apr 16 '14 at 23:01
  • Related, but not quite a duplicate: [How do I fix merge conflicts in Git?](http://stackoverflow.com/questions/161813/how-do-i-fix-merge-conflicts-in-git). –  Apr 16 '14 at 23:14
  • possible duplicate of [Tortoise Git - lost commits after a pull resulted in conflicts](http://stackoverflow.com/questions/23120311/tortoise-git-lost-commits-after-a-pull-resulted-in-conflicts) –  Apr 17 '14 at 17:35

2 Answers2

0

Your original question is the wrong one. Your workflow is broken so you are getting lots of conflicts. You should fix that. In the case that you do get a merge conflict, the state of the tree is that incoming changes are automatically staged and changes that need manual intervention will be in the working environment. For each un-staged file, users need to resolve conflicts and stage the changes. Once everything is ready you can commit the entire change set. This will be a merge commit so it should not contain new functionality or logic. If you unstage a file during this time, you are essentially over-writing the incoming change with the version that is in your local copy.

As for the deeper problems in your workflow, it sounds like people are committing directly to master. This is your main problem. No one should be committing directly to your trunk. Instead, folks should start working in a fresh branch. Even if the change is for one file, a productive git workflow very much relies on branching. Once the work in the branch is complete, you can merge your branch into master, or merge master into your branch. You can also re-base your branch in order to avoid multiple merge commits, although I have found that to be unnecessary.

I work flow would look like this:

 # git checkout master
 # git pull
 # git branch newbranch
 .
 .
 Do work
 .
 # git merge master     <!-- Optional to pull in changes from master -->

 .
 .
 # git add <files>
 # git commit
 # git checkout master
 # git merge newbranch
Zeki
  • 5,107
  • 1
  • 20
  • 27
  • This doesn't actually solve the original poster's problem. His problem was that he doesn't understand why TortoiseGit was staging files that he wasn't responsible for during the resolution of merge conflicts. The fix is simply to leave those staged files alone. It has nothing to do with the kind of workflow he is using. –  Apr 17 '14 at 00:15
  • Although it is true that the right thing to do is to ignore staged files during a merge conflict, the fact that conflicts are occurring so frequently is indicative of a deeper workflow problem. I've updated my answer to clarify... – Zeki Apr 17 '14 at 00:19
  • Probably best to rephrase "No one should be committing directly to your trunk" so that it's more obviously an opinion. For frequently-released projects (anything using real continuous delivery), committing directly to master is optimal. I found [this comparison](http://blogs.wandisco.com/2013/07/24/git-workflows-and-continuous-delivery-using-multisite-replication-to-facilitate-a-global-mainline/) quite useful. [Atlassian's comparison](https://www.atlassian.com/git/workflows#!workflow-centralized) is also good, though it makes no recommendations. – Paul Hicks Apr 17 '14 at 00:37
0

I shall address your questions line by line:

First, why does Git or TortoiseGit just show a list of files that the user has nothing to do in the list?

When you merge in file changes from another branch, those changes may of course contain work from other people. That is why you see file changes that aren't necessarily yours. They represent all the changes that you're trying to merge in.

Second, what is the correct thing to do in this scenario - any answer from a TortoiseGit perspective will be helpful.

By un-checking files while you're resolving merge conflicts, you're essentially telling TortoiseGit that you don't actually want to merge/keep those file changes. You're basically saying "I don't want these changes, just throw them away". If that's not what you actually want to do, then don't un-check those files that TortoiseGit has automatically staged to be committed for you, even if you weren't originally responsible for the changes in those files.