2

My Developer team and I are starting to run in a few issue more often then not involving git. We all work off the same branch called mysql_trunk. We constantly run into push conflicts and merge conflicts.

We are comfortable using git but we feel were missing something here. There must be a more efficient way of handling large code base(1.5mil lines of code) with multiple developers all contributing to the same repo at the same time. This may seem like a fairly straight forward question but we could really use some help in finding a solution to prevent us from constantly having push conflicts, merge conflicts, detached HEAD conflicts.

Any suggestions and/or reading material will be greatly appreciated.

umläute
  • 28,885
  • 9
  • 68
  • 122
Charles L.
  • 1,844
  • 2
  • 34
  • 56
  • If you're constantly running into merge conflicts it *probably* means you have some files that everybody touches constantly. If this is correct you should consider splitting up these files or refactoring them to separate the responsibility. "God classes" usually end up like this. – Lasse V. Karlsen May 03 '17 at 20:46
  • As for push conflicts, yes, this will happen, but are you all working directly on the branch? Are you doing small features? Or larger features? Have you considered feature branches so that you can work more or less in isolation until a feature is done? This should alleviate *some* of the contention around the main branch. – Lasse V. Karlsen May 03 '17 at 20:47
  • Its generally small features bug fixes, with the occasional large feature set. – Charles L. May 03 '17 at 20:48
  • Git allows for a lot of workflows to be implemented. Are you all pushing at the same level? Like, there's no hierarchy? Taking advantage of developers, technical leads and integration leads and so on to accept code into their branches (to make it into "higher" branches) could help a lot (in many ways). https://www.atlassian.com/git/tutorials/comparing-workflows – eftshift0 May 03 '17 at 20:52
  • Possible duplicate of [How to avoid git conflicts in a team?](http://stackoverflow.com/questions/16490873/how-to-avoid-git-conflicts-in-a-team) – umläute May 03 '17 at 20:56

1 Answers1

6

Given that git is used (and developed for) the Linux kernel, 1.5MLOC does not seem a particularly large codebase (the kernel is about 10 times as big). your number of concurrent developers, is probably also way smaller than that of Linux.

So the question is, why do you get those conflicts in the first place?

In any case, there are a number of ways to avoid merge conflicts. here's a few (inspired by 4 Simple Tricks to Avoid Merge Conflicts )

  • commit often, do minimal atomic commits, commit often. (don't let a re-indentation of the code file spoil your bugfix commit)

  • make sure to use the same coding conventions (esp. whitespaces)

  • create feature branches, but make them short-lived and merge them asap (the less a branch diverges from trunk, the less chances there are for a conflict)

  • organize the code in a modular way: if developers working on different/unrelated tasks need to change the very same lines of code, then you have a problem with your code organization - and no VCS will be able to help you.

  • communicate (if your code is already modular, then make sure that people who work on the same code, work together rather than against each other; they should know which parts of the code will change in the near future, so they can hold back their own changes)

  • commit often

  • make sure that you are tracking only human-edited files (no binaries, no textual build artifacts (e.g. autotools files)

  • commit more often

umläute
  • 28,885
  • 9
  • 68
  • 122