Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
62 lines (40 sloc) 4.81 KB

Using Git with a Team

Despite working with Git/Mercurial since 2012, I'm still trying to figure out the best way to organize everything. It really all comes down to whatever works for your collaborators. Q.E.D. This is what works for me.

Typical Development Workflow

  1. git pull to get the latest from develop
  2. git checkout -b prefix/TICKET#.shortDescrip to create your own working branch
  3. Make your changes to your branch. Commit frequently to avoid losing work by accident
  4. git push your working branch to the remote repo
  5. Create a pull request for your branch with the appropriate merge target (develop or release/*)
  6. Once you get the requisite approvals, YOU merge your own code back in.

Yes, you, the author of the new code, are responsible for merging your own code. That's not quite the same as a traditional "pull" request, but the reasoning is that you are more aware than your reviewers as to what other work is going on. Maybe your branch should wait until after your teammate's other fix is merged.

Branching vs Fork?

Branching is the best strategy for the project's core team. Forking is better suited to a third-party project you would like to contribute to, but are not a core maintainer of.

Why? No reason beyond the fact that the terminology implies a certain intent in my mind. If I'm adding a feature to a codebase that I fully intend to become part of the main codebase, then conceptually it's a branch that will eventually merge back to the trunk. On the other hand, if I'm extending say JQuery that my project uses as a dependency, but the core JQuery team may not agree on its general usefulness, then I'll probably want to fork from the start. You can merge branches and forks back into the trunk, so I realize it doesn't make a huge difference.

Branching Strategy

I like using a loose version of git-flow which basically works as follows.

branch: feature/TICKET#.description - These will be the working branches for individual developers, e.g. feature/PRJ-1234.addUserFeature. The "release/" prefix is arbitrary, but some services like Github, Bitbucket, JIRA, etc. can use it for deployment pipelines and integrations. There are some other special prefixes too:

  • bugfix/ To denote an issue with deployed code, as opposed to a brand new feature
  • release/ Release branches/tags. These don't tend to change much after they are deployed unless you have a...
  • hotfix/ This is a bit less common and is the same as a bugfix, except it indicates it should ONLY be merged back to a release branch, and probably not the main trunk.

branch: develop - This is the main trunk that developers will merge to on a regular basis. Release branches are cut from here, and feature branches should merge back into here.

branch: master - This branch only ever receives updates from merging in develop, and is meant to only contain deployed, validated, tested and accepted code.

branch: release/RELEASE# - A mostly-static branch that is a snapshot of what was deployed to production, e.g. release/v1.0.5

Branching Example

Suppose you had a release on January 1, and the next quarterly release on April 1 will have three new features. On February 20, Feature 1 is completed, but Features 2 and 3 are still in progress. You would have the following branches:

  • master - Snapshot of the code that was deployed on January 1
  • release/Jan1 - Snapshot of the code that was deployed on January 1; same commit as master
  • develop - Includes the code from Feature 1, which was in feature/Feature1 that has since been closed after merging
  • feature/Feature2 and feature/Feature3 - Works in progress

On April 1, assuming everything is completed...

  • master - Now includes everything from the first release, plus Features 1-3
  • release/Jan1 - Should retain the OLD commits only, meaning it does not have Features 1-3.
  • release/Apr1 - Same commit as the master branch is now.
  • develop - Same commit as the master branch is now.
  • feature/Feature(1-3) - All should be closed since they are merged

On April 5, a bug is discovered, but it will only affect the Apr1 release because the affected feature is going to be retired next quarter. (These kind of version-specific are usually due to changes in the database schema or data model, etc.)

  • master - Now includes everything from the first release, plus Features 1-3
  • release/Jan1 - Should retain the OLD commits only, meaning it does not have Features 1-3.
  • hotfix/Apr5Bug - Fixes the bug that was discovered, and should be closed after getting merged into release/Apr1
  • release/Apr1 - Should now include the fixes in hotfix/Apr5Bug
  • develop - Still the same commit as the master branch, or the OLD release/Apr1 commit before the hotfix.
You can’t perform that action at this time.