Gitflow: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
(Replaced content with "=Internal= * Git * Trunk-Based Development * GitHub Flow * Semantic Versioning =Subjects= * Concepts * Operations")
Tag: Replaced
 
(60 intermediate revisions by the same user not shown)
Line 1: Line 1:
<center><font color='darkgray'>Work in progress, Gitflow Workarea available.</font></center>
=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=
=Internal=
* [[Git]]
* [[Git]]
* [[Trunk-Based Development]]
* [[GitHub Flow#Overview|GitHub Flow]]
* [[Semantic Versioning]]


=Overview=
=Subjects=
 
* [[Gitflow_Concepts#Overview|Concepts]]
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.
* [[Gitflow_Operations#Overview|Operations]]
 
git-flow comes with a well-defined set of branches, where each branch (or each branch type) has a specific role:
* <span id='Master'></span>The '''master''' branch stores the official release history. The master contains the abridged history of the project, unlike [[#Develop|develop]], which contains the complete history.
* <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='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='Hotfix'></span>'''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|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|master]] or [[#Develop|develop]], or the current [[#Release|release]] branch, if there’s one in progress, and [[#Master|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=
 
==git-flow-Enabling a Repository==
 
git flow init
 
Which branch should be used for bringing forth production releases?
  - develop
Branch name for production releases: [] master
Which branch should be used for integration of the "next release"?
  - develop
Branch name for "next release" development: [develop] develop
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] release
Hooks and filters directory? [/Users/ovidiu/UpLift/github/up.plat-svc.fds/.git/hooks]
 
==Create a Feature Branch==
 
git flow feature start <''feature_branch_1''>
 
Note that the repository must be "git-flow enabled" for this to work. See [[#git-flow-Enabling_a_Repository|git-flow-enabling a repository]].
 
The equivalent standard commands:
 
git checkout develop
git checkout -b <''feature_branch_1''>
 
Note that this command does not push the newly created feature branch into the origin repository. If you wish to do so, follow: {{Internal|Git_branch#Create_the_Remote_Branch_and_its_Local_Remote-Tracking_Branch|Create the Remote Branch and Its Local Remote-Tracking Branch}}
 
In our case is:
 
git push origin feature/<''feature_branch_1''>
git branch --set-upstream-to=origin/feature/<''feature_branch_1''> feature/<''feature_branch_1''>
 
==Finish the Feature==
 
git flow feature finish <''feature_branch_1''>

Latest revision as of 17:20, 6 March 2024

Internal

Subjects

Retrieved from "https://kb.novaordis.com/index.php?title=Gitflow&oldid=108234"