Gitflow: Difference between revisions
Jump to navigation
Jump to search
| Line 19: | Line 19: | ||
* <span id='Develop'></span>The '''develop''' branch serves as integration branch for features. This branch contains the complete history of the project. | * <span id='Develop'></span>The '''develop''' branch serves as integration branch for features. This branch contains the complete history of the project. | ||
* <span id='Feature'></span>'''Feature''' branches serve to develop features. Each feature should reside on its own branch. The feature branches branch off [[#Develop|develop]], not [[#Master|master]]. When a feature is complete, the corresponding feature branch is merged back into [[#Develop|develop]]. Features should never interact directly with master. | * <span id='Feature'></span>'''Feature''' branches serve to develop features. Each feature should reside on its own branch. The feature branches branch off [[#Develop|develop]], not [[#Master|master]]. When a feature is complete, the corresponding feature branch is merged back into [[#Develop|develop]]. Features should never interact directly with master. | ||
* <span id='Release'></span>'''Release'' branches host release preparation development. Once [[#Develop|develop]] contains enough features for a release, or the schedule release date is approaching, a new release branch is forked off [[#Develop|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|master]] and tagged with a release number and 2) the release branch is merged back into [[#Develop|develop]]. Merging the release branch back into [[#Develop|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. | * <span id='Release'></span>'''Release''' branches host release preparation development. Once [[#Develop|develop]] contains enough features for a release, or the schedule release date is approaching, a new release branch is forked off [[#Develop|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|master]] and tagged with a release number and 2) the release branch is merged back into [[#Develop|develop]]. Merging the release branch back into [[#Develop|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. | git-flow is a merge-based solution. It does not rebase feature branches. | ||
Revision as of 23:30, 5 October 2018
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.