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.
git-flow is a merge-based solution. It does not rebase feature branches.