Question

I use Git to help delegate the course of a project, whose code-base is simultaneously developed by a growing team of developers. It does nearly everything we need it to do, however every so often a particular obstacle arises, whose solution escapes me: someones code gets kicked out.

At first this question sounds fairly generic, but I’m unaware how to “categorize” this problem, and moreover I’m not sure of the most effective way to diagnose it. I can explain it, however, in a quick play-by-play.

Play-by-play

Setup: We have three environments: A, B, and C. Each is a clone of a central repository.

• A just fixed a feature. B & C still have the broken version.
• B wants A’s code, to make cosmetic changes to the corrected functionality.
• C is my environment, and I perform the Git tasks.
• I merge B & C first, because any conflicts will be easier resolved.
• I push this result, then pull it into A, and resolve conflicts there.
• I push this result, then pull it into B & C.

Suddenly, A’s solution is gone. The feature is, again, broken everywhere. I get the impression that A’s new, corrected code was mistakenly replaced.

Question #1: Is order the problem?

I’m under the impression that the order in which different clones push and pull shouldn’t change the result. Am I correct? Or is my problem to do with the order of the pushes and the pulls?

Question #2: What tools are useful for diagnosing this issue?

Even after using git diff and GUI log tree-views, like in gitk or TortoiseGit, the solution is sometimes still unclear. Are there any other tools in the Git suite, or otherwise, which indicate how code moved, or how preference is determined?

Answer 1

No, the order doesn’t matter. Your problem is somewhere in the details you’re omitting about how you’re doing the merges or resolving conflicts. You’re not committing something that needs it at the right time, or you’re using --force when you shouldn’t, or accidentally working out of the wrong repo at some point, or something like that.

What I would recommend is testing your feature and running a git status and git log between every small step, to make sure what is committed is what you think is committed. git reflog in A’s repo is a good resource for helping you see when your changes disappeared and getting them back, but you need to narrow down what exact step is causing your issue.

Also, if I may make a suggestion, if you’re doing all the git tasks yourself, you don’t really need a separate central repository, as it just adds superfluous steps. If B wants A’s code, it should be as simple as a pull directly from A to B. Then when B is done with the cosmetic changes, pull directly from B to everyone else. Trying to merge everything, everywhere, every time is bound to trip you up sooner or later.