0

We're running GitLab as our central Git repo and using TortoiseGit locally along with VS2010 SP1 as our main IDE, developing ASP.NET application. We've transitioned from TFVC to GIT 2 months back and we are still newbies. We branches on every bug fixes and we only use merge with no-ff exclusively for now.

We're working on a new feature branch, and there's 4 developers working on it excluding myself. Last week we discovered that some production bug fixes which were merged into this feature branch were overwritten by one of the developer (dev-A). Upon investigation, we suspected that dev-A might have commit an older version of the code in his local repo, and subsequently pushed it to the server. We couldn't find out the exact thing that he did as he wasn't sure himself and this happened about 3 weeks ago.

When we checked the commit network in the logs and also on GitLab, there appears to be 2 lines where on one line, dev-A committed the conflicting code locally and continue working before pushing to the server 2 weeks later and the other line where the maintenance team merged the last production bug fixes. The line converge when when dev-A did a pull from server and merge and the first conflict happened. I assisted him and noticed the large number of conflicts, but I was assuming it's normal, although the conflicts are not conflicts at all, i.e. 0 line vs few lines of code. After that when the next developer (dev-B) pull from server to get the latest code, the same list of files appears in the merge and with the same conflicts. This is when we started to suspect something. Our initial investigation also found that some bug fixes were actually reversed.

We've got everyone to push to their own branches for now (feature-name), while we try to access the situation. We're worried that the conflicts will keep going round and round as we pull/merge/push. I wonder if we need to go back in history to delete that particular offending commit but We would like to retain the rest of the useful history. Any pointers to investigate and to move forward would be helpful.

Thanks and sorry for the lengthy explanation.

faulty
  • 8,117
  • 12
  • 44
  • 61

2 Answers2

2

From my experience I can guess that the mess is coming from using a TortoiseGit, in my case it was a SourceTree, when committing after the conflicts resolution. The flow is approximately as following:

  1. The developer tries to merge a remotes changes and conflict happens
  2. The developer resolves conflicts.
  3. The developer reviews his changes. This is a faulty step. The developer looks at the index and finds that there are files that he didn't touch. So he unchecks these files at the UI, and actually he does git rm --cached <file>, that means, removes the file from the index.
  4. The developer commits the changes

As a result of step 3, the unchecked/removed files are being reset to the local copy of the developer and the remote changes has gone.

In order to prevent this in the future, guide your developers never to intervene the merge process except editing and adding to index the files with conflicts.

I believe a good start point to find all possible merges where conflict resolution was done, will be git log --merges --grep "Conflict".

Good Luck !!!

Yuri G.
  • 4,323
  • 1
  • 17
  • 32
  • Thanks, I was involved with all the conflict resolution and we manually edit the files then commit all pre-selected files, all from the UI with default options. I managed to fixed the issue after further investigation, I'll answer my own question shortly. – faulty Nov 09 '15 at 11:18
0

After further investigation, we suspect that dev-A paste over an older copy of the folder saved during TFS transition, and hence a bunch of older files which was committed as new changes resulting in conflicts and reversal of latest bug fixes.

We later found out that we can actual commit as another user and with a custom timestamp, via the UI, hence we choose to create a new feature branch, "replay" all commits from dev-A minus the offending one, and pull/merge with the existing 2nd line update, rebase the latest changes from dev-B, then rename the existing feature branch and push this new branch to the server, then have everyone checkout the new branch overwriting their local repo.

Things seems to be alright for now. We got most developers to check on their codes and will keep the old branch for a while, just in case. Next up would be to draft a stricter guideline for all developers to follow.

faulty
  • 8,117
  • 12
  • 44
  • 61