We've been using Git as our version control but as the team grows, there are more and more pains when it comes to getting all our changes onto a single branch ready for a deployment.

I'm wondering if maybe we're outgrowing Git as an effective collaboration tool. I know there are large OSS projects with many developers that use Git but there also tend to be some gatekeepers responsible for the merging of branches into the final build/deployment branch.

In an office environment, where the developers are relatively independent and can be trusted to merge their own changes, how many people can effectively collaborate on Git?

Additionally, are there any tips for effective use of Git? We've been using the rebase workflow, I'm not entirely convinced switching to a merge based workflow would improve the situation but then, I haven't seen a formal description of how a large group would work together in a merge workflow (It seems like the history would just turn into merge hell).


So that it's easy to find for anyone else wondering:

  • We're using a feature branch strategy
  • The code base is well organized and pretty clean. It's Python (with some HTML/JS), MVC via pyramid for the web app, separate package (different top level folder in same repo, itself split up into well defined layers) for a large chunk of the non-web specific application functionality.
  • We experience pain as far as merging code because developers are frequently making changes in the same files, like, one dev owns auth, so they're touching the views, etc... related to auth, but another dev is handling internationalization, so they're touching all the views, etc.
  • How are you handling branches? Are you Branching per feature or is everyone sharing a "development" branch or...there are many options. Which branching strategy are you using? – Michael Brown May 30 '13 at 21:06
  • I would first take a closer look at the quality of your code and design. If it's unmaintainable spaghetti, forcing developers to spread changes for specific feature all over the codebase, then neither VCS nor branching strategy will help – gnat May 30 '13 at 21:10
  • @MikeBrown feature branches – Endophage May 30 '13 at 22:20
  • @gnat we have a pretty clean codebase, which really causes more pain as far as merging code because developers are frequently making changes in the same files. – Endophage May 30 '13 at 22:21
  • 1
    hm these two statements somehow don't sound realistic together; I would rather expect either 1) clean codebase or 2) "developers are frequently making changes in the same files" than both 1) and 2) – gnat May 31 '13 at 6:08

Well, git is up to the task to handle the linux kernel, right? It worth a look to feel the number of patches, branches, contributors....

Based on that I don't think there is a size limit. Also I doubt there exist any better source control system these days, so even if it had, nothing to switch to.

However I feel for your problems, those are definitely real. You need project organization. You need check-in rules, code policies, branching policy, culture, and a lot of other teamwork related things for good results. git is merely a database with convenient features to store and manipulate sources and history. It never pretended as a "system" or replacement for one. Or a general collaboration tool.

For non face-to-face collaboration there are actually good supplement tools like bugzilla, wikis, project planners. We use FogBugz with Kiln -- the latter just learned git, and it allows to streamline many workflows related to assigment of tasks, verification and especially reviews. You need to assemble some system like that. And certainly keep up real people interactions and a learning environment.

For git history handling, yes, I also suggest rebasing for most times, especially single patches. But use branch merges, even on top with --no-ff if for a single topic. Before integration to master make the code reviewed and consolidated (rebasing on self) to meld fixups and post-review work. Don;t be afraid to fix the master if it goes out of shape.

To avoid "upstream reabase" related problems my rule is to create an amend_NN branch on the old and fixed_NN on the new state with matching numbers, so anyone can easily discover that his work must be rebased and avoiding resurrect of dropped things.

The branching policy must be based on the general work and release approach. I keep a single master but you can find more elaborate schemas that have a separate development master.

NOTE: By 'bugzilla' I meant the tracker genre in general not the particular product directly, in decision making I got great help from tracker compare wiki . OTOH I do have positive experience with Bugzilla itself from previous places too.

  • Bugzilla is not a particularly great example of bug tracker. The commercial, but rather cheap, FogBugz is often very much praised, but if you wanted a free solution I recommend looking around first. – Jan Hudec May 31 '13 at 9:04
  • Linux was the project I was thinking of with strict gatekeepers. We have Jira, Confluence and are ramping up Crucible but then I'm still working out exactly how Crucibles code review system works as it doesn't do pull request style like github or sandbox your commit like gerrit. – Endophage May 31 '13 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.