11

I'm working on a git workflow to implement in a small team. The core ideas in the workflow:

  • There is a shared project master that all team members can write to
  • All development is done exclusively on feature branches
  • Feature branches are code reviewed by a team member other than the branch author
  • The feature branch is eventually merged into the shared master and the cycle starts again

The article explains the steps in this cycle in detail:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

Does this make sense or am I missing something?

|improve this question

migrated from codereview.stackexchange.com Nov 7 '12 at 22:03

This question came from our site for peer programmer code reviews.

16

I like the git flow branching model. The master branch is left alone most of the time, it only contains releases. The develop branch should be stable at all times, and the feature branches can be broken.

You can also combine this with continuous integration by merging develop into your feature branch and your feature branch into develop. Of course you should only merge something into develop when you're confident that things are working and do not break.

|improve this answer
  • As I understand it git flow and continuous integration are alternative ways of working and can't really be combined. In git flow the code is merged into develop only when a feature is complete. In continuous integration all code is merged into a shared branch at least once each day, even if it doesn't provide any new feature immediately. – bdsl May 31 '17 at 21:36
7

I think you are missing the topic Continuous Integration. It should be part of every development setup.

With feature branches you have the problem, that you don't integrate continously, but only after a feature is completed.

If the feature branched is short lived, this might be acceptable, but it is definetly something one should consider.

Another alternativ is to setup CI builds for each feature branch. This sure does help, but it isn't integration. This becomes obvious once you find your first bug that doesn't appear in Feature A nor Feature B, but in the moment where you integrate Feature A&B

A third alternative is to make merging in some integration branch part of the CI build. This is true integration, and actually works reasonably well with git if the work is somewhat seperated, but causes merge conflicts during the build resulting in failed builds.

|improve this answer
  • The master branch can be hooked up with a CI to reject feature branch merges if they fail the automated non-regression tests. Thanks for the tip, I will add a "Tips" section at the end and mention this there. – janos Nov 7 '12 at 12:01
  • 1
    Sure, but as said, this is not continuous-integration but at-the-end-of-a-feature-integration which might be good enoug, but isn't the same – Jens Schauder Nov 7 '12 at 12:14
  • 1
    I think that feature branches are very useful, because they do not need to be stable. That means you can commit frequently instead of having one huge commit. – Arjan Nov 7 '12 at 20:58
  • An automated build process that runs on a schedule (CI system) is indispensable. It needs to run often so that compile problems can be found and fixed quickly. Dev teams should give build failures the highest priority. It's a lot easier to fix these types of problems when they first surface. – Nathan Pilling Nov 7 '12 at 23:56
  • 1
    For our projects that use CI (we have a couple of legacy projects that can't use it at the moment), we commit EVERYTHING to master for true CI, for our legacy projects we use the git flow branching model. Feature branches are a CI blocker if you ask me, they make it harder to CONTINUOUSLY (not only when it's finished) integrate. We keep working on features and the final task is to turn it on basically, but the code is always in the project. – Elliot Blackburn Dec 30 '14 at 12:42
1

You can get inspired to gitflow or Twgit.

gitflow summarizes its approach as:

Git extensions to provide high-level repository operations for Vincent Driessen's branching model.

Twgit describes itself as follows:

Twgit is a free and open source assisting tools for managing features, hotfixes and releases on Git repositories. It provides simple, high-level commands to adopt the branching model describes in our documentation. Supported OS: Debian/Ubuntu Linux, Mac OS X.

Both tools are available from github.

|improve this answer

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.