Branching

Distributed version control systems like Git give you flexibility in how you use version control to share and manage code. Your team should find a balance between this flexibility and the need to collaborate and share code in a consistent manner.

Team members publish, share, review, and iterate on code changes through Git branches shared with others. Adopt a branching strategy for your team. You can collaborate better and spend less time managing version control and more time developing code.

Recommendations

• Keep to the simplest initial branching strategy
  • Use releasable units which are shippable to define a release structure
  • Start a new strategy with the main-only branching strategy
• When a release is ready to start, create a release branch
  • This is used to stabilize the release. Development of the next release can continue on the source branch
  • Reverse-integrate and merge any valid bug fixes back into the source branch
  • Update the build definition for release as the release branches are retired and recreated
• Expand the branch strategy only when the need arises
  • Use the feature isolation branch strategy to develop features which need isolation from the regular development for the next release.
  • Only merge feature isolation branches when the feature is releasable.
  • Consider feature isolation when multiple teams are working in the same artifacts, to limit cross team merge to whole branch reverse integration merges.
• Use consistent behavior on all branches
  • All branches created should be setup for continuous integration
  • Label release points for convenience. Do not rely on labels for history or as a constant, labels can be changed.
  • Use a naming convention for branches. Example:
    • Release 1.00 or Release 2019.10.14
      • Release [major]. [minor] or Release [year]. [month].[day] - indicates a release branch for a version or target date.
    • Feature [Name] or Release 1.00 Feature [Name]
      • Feature [name] or Release [major].[minor] Feature [name] - indicates a feature by name or for a specific release (source label) and feature by name.
• Only create branches when absolutely needed. Branches have cost:
  • Merging changes and reverse integration while frequently automatic, takes more time as the complexity and time from last merge or integration increases
  • Set consistent release points, use feature isolation branches to create control over introducing features.

GitFlow

When you work with GitFlow, branches typically represent a ‘stage’ in your code lifecycle and follow a specific naming convention:

• develop: Integrates all features from developers. With GitFlow, commits within this branch should always be a merge commit (from a feature, release or hotfix) branch. It means that, as a developer, you shouldn’t commit directly in it (but, again, you can) and the develop branch should always be ‘stable’ (i.e. no deployment or build errors).
• master: the latest stable version ready for production and deployable at any time. Commits in this branch should always come from release or hotfix branches
• release/{version}: final validation before the production deployment. For instance, adjust the documentation, write the changelog, resolve minor bug fixes etc. You don’t develop any new feature here. When it is done, the update is merged to develop and master to reflect the latest version of the code.
• feature/{feature name}: represent a new feature for your product. You can start many features in parallel if you want.
• hotfix/{version}: used to fix a bug encountered in production that you need to fix right now. That’s why you always start a hotfix from the master branch. Like the release branch, when it is done, the update is merged to both develop and master.

Branches & Environments Relations

The overall flow of Gitflow is

• A develop branch is created from master
• A release branch is created from develop
• Feature branches are created from develop
• When a feature is complete it is merged into the develop branch
• When the release branch is done it is merged into develop and master
• If an issue in master is detected a hotfix branch is created from master
• Once the hotfix is complete it is merged to both develop and master
  • All Pull Requests must be against develop branch.

Code Review (Pull Requests)

Pull requests combine the review and merge of your code into a single collaborative process. Once you're done fixing a bug or new feature in a branch, create a new pull request. Add the members of the team to the pull request so they can review and vote on your changes. High quality reviews start with high quality feedback. The keys to great feedback in a pull request are:

• Have the right people review the pull request
• Make sure that reviewers know what the code does
• Give actionable, constructive feedback
• Reply to comments in a timely manner

Demo in Arabic