Gitflow
Jump to navigation
Jump to search
External
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- http://nvie.com/posts/a-successful-git-branching-model/
- https://danielkummer.github.io/git-flow-cheatsheet/
- https://github.com/petervanderdoes/gitflow-avh/wiki/Installation
- http://weaintplastic.github.io/web-development-field-guide/Collaboration/Working_with_Git/Git_Workflow/The_Concept_of_Gitflow
Internal
Overview
git-flow defines a branching model that is tightly coupled with the project release cycle. This model is suited for projects that have a scheduled release cycle.
git-flow comes with a well-defined set of branches, where each branch (or each branch type) has a specific role:
- The master branch stores the official release history. The master contains the abridged history of the project, unlike develop, which contains the complete history.
- The develop branch serves as integration branch for features. This branch contains the complete history of the project.
- Feature branches serve to develop features. Each feature should reside on its own branch. The feature branches branch off develop, not master. When a feature is complete, the corresponding feature branch is merged back into develop. Features should never interact directly with master.
- Release branches host release preparation development. Once develop contains enough features for a release, or the schedule release date is approaching, a new release branch is forked off develop. The creation of the release branch starts the release cycle: no new features can be added after this point, only bug fixes, documentation and other release-related content. Once the release work is finalized: 1) the release branch is merged into the master and tagged with a release number and 2) the release branch is merged back into develop. Merging the release branch back into develop is critical because important updates may have been added to the release branch during the release process and we want those into the main development state. Having a dedicated release branch facilitates communication regarding the specific release: "we're preparing version 7.7". After release and merging, the release branch should be deleted.
- Hotfix (or "maintenance") branches carry maintenance work for functionality that was released. The results of the maintenance work are used to patch production releases. Hotfix branches are based on master. These are the only branches that fork off directly from master. As soon the fix is complete, it should be merged both in master or develop, or the current release branch, if there’s one in progress, and master should be tagged with an update release number. Maintenance branches can be thought of as ad-hoc release branches that work directly with master.
git-flow is a merge-based solution. It does not rebase feature branches.
git-flow is supported by a toolset that can be installed, and which provides specialized command line extensions.
Installation
Mac
brew install git-flow-avh
Operations
Create a Feature Branch
git flow feature start <feature_branch_1>
The equivalent standard commands:
git checkout develop git checkout -b <feature_branch_1>