1

We have a small team, using a modified GitFlow workflow. One developer just commits and pushes directly to develop; the others create topic/feature branches as needed. We've noticed once or twice that when we merge and commit one of our branches, some changes to develop from the other guy just go missing. We're pretty sure that we're pulling from origin/develop every single time before doing the merge and merge commit to (local) develop.

The probability that it's us, and not Git, approaches unity. But where are we going wrong?

Here's a screenshot from SourceTree. When Sarah merged the branch at the top into develop and pushed, some of Joe's changes (e.g. the ones from 19-Apr-2017 11:56) just vanished, even though she had not been working in those files (confirmed by the log).

I get that we're probably doing something stupid. But for the life of me, I can't figure out what!

enter image description here

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
Rick Wayne
  • 11
  • 2
  • "One developer just commits and pushes directly to develop" - that doesn't sound like a great workflow. – Oliver Charlesworth Apr 21 '17 at 17:33
  • When Sarah pushed, was it a forced push? And I mean, a forced push that didn't include the revision that vanished? Cause if it is a forced push, that explains why the changes "vanished". – eftshift0 Apr 21 '17 at 17:36
  • In general, as long as we disregard corrupted repositories and willfully removing/reversing, there are two reasons why anyone would lose changes/code in Git, and would be that a merge conflict arose and someone incorrectly resolved the conflict in such a way to disregard some changes, or someone did a force-push. Have you verified either possibility with the developers involved? – Lasse V. Karlsen Apr 21 '17 at 17:48
  • 1
    OK, go ahead and laugh, but other than noting its presence as a checkbox in SourceTree, I had NO IDEA what a force-push was. Pretty sure no one on the team is that much of a Jedi (it's a joke, Ah say a JOKE, son!). I did a push from Sarah's machine using her copy of ST and I know the "force push" box was unchecked when I did so; she also avers that she didn't do that. Good hypothesis, though! (I'll check with Joe too, though his code didn't overwrite, but got overwritten.) – Rick Wayne Apr 21 '17 at 18:13
  • Further: Sarah checked and "Enable force push" is unchecked in her ST config; she can't do a force push if she tries, because that option is greyed out in the "Push" dialog. ??? – Rick Wayne Apr 21 '17 at 18:21
  • So, in commit "20 Apr 2017 12:03" (later `J`) the Joes's changes in file `` are still there, but in "20 Apr 2017 17:55" (later `M`) they are removed. You should check with Sarah then how the merge is done. Were there any conflicts, how they were resolved? – max630 Apr 21 '17 at 18:25
  • It's not a forcepush if we trust the screenshot – max630 Apr 21 '17 at 18:26
  • Command `git log J..S -- _file_` where `J` is the "20 Apr 2017 12:03" commit and `S` is "20 Apr 2017 17:42" should show if Sarah really did not change the `_file_`. Sometimes there are automatic changes made by IDE or something. – max630 Apr 21 '17 at 18:45
  • Just an idea if you know the file or what "word" changes: try `git blame ` to see who changed it or have a look [here](http://stackoverflow.com/a/2929502/5784831). – Christoph Apr 21 '17 at 20:37
  • I have a little project that could help you find out who deleted something. https://github.com/eantoranz/difflame Hope you find it useful. – eftshift0 Apr 21 '17 at 20:39
  • Without access to your repository and watching the actual merge process happen, it's hard to guess what's going on. You can, however, compare the merge commit's tree to *each* input (parent) tree by using the command line `git show -m `. The `-m` here means "diff the merge against parent#1, and show me that, then diff the merge against parent#2 and show me that too." Add `-- ` to view just the changes to that file. – torek Apr 22 '17 at 04:39
  • You can make `develop` a protected branch which would prevent others from pushing directly to it, which might fix things? Then you'll have to use a merge request-based workflow. – Connor Shea Apr 25 '17 at 21:32

0 Answers0