Gitflow using source tree
In early 2010, Vincent Driessen wrote an article called “A successful Git branching model” which recommended an approach called git-flow to use git branches in your development cycle.
The idea was to standardise branching and merging when developing
features, handling releases and managing hot fixes, in order to be consistent
and gain the advantages of git’s ‘branchy’ development model. Using many
separate branches in Git gives you lots of flexibility, but it can get complex.
Adopting a standardised approach has many advantages:
·
Keep your repository tidier
·
Keep your procedures clearer
·
Move between projects more easily with familiar branch structures
·
Get new developers up to speed more quickly
SourceTree now integrates with
git-flow and presents it to you in a friendly and intuitive way.
Summary of the concept
The general idea of git-flow is to use the following branch structure in
your repository:
·
Development branch (usually
called ‘develop’)
This is your main development branch where all the changes destined for the next release are placed, either by directly committing small changes or by merging other branches (e.g. feature branches) into this branch.
This is your main development branch where all the changes destined for the next release are placed, either by directly committing small changes or by merging other branches (e.g. feature branches) into this branch.
·
Production branch (usually called ‘master’)
This branch represents the latest released / deployed codebase. Only updated by merging other branches into it.
This branch represents the latest released / deployed codebase. Only updated by merging other branches into it.
·
Feature branches (usually prefixed with
‘feature/’)
When you start work on anything non-trivial, you create a feature branch. When finished, you’ll merge this branch back into the development branch to queue it for the next release.
When you start work on anything non-trivial, you create a feature branch. When finished, you’ll merge this branch back into the development branch to queue it for the next release.
·
Release branches (usually prefixed with
‘release/’)
When you’re about to package a new release, you create a release branch from the development branch. You can commit to it during your preparation for a release, and when it’s ready to be deployed, you merge it into both the development branch and the master branch (to indicate that the release has been deployed).
When you’re about to package a new release, you create a release branch from the development branch. You can commit to it during your preparation for a release, and when it’s ready to be deployed, you merge it into both the development branch and the master branch (to indicate that the release has been deployed).
·
Hotfix branches (usually prefixed with ‘hotfix/’)
If you need to patch the latest release without picking up new features from the development branch, you can create a hotfix branch from the latest deployed code in master. Once you’ve made your changes, the hotfix branch is then merged back into both the master branch (to update the released version) and the development branch (to make sure the fixes go into the next release too)
If you need to patch the latest release without picking up new features from the development branch, you can create a hotfix branch from the latest deployed code in master. Once you’ve made your changes, the hotfix branch is then merged back into both the master branch (to update the released version) and the development branch (to make sure the fixes go into the next release too)
SourceTree helps you utilise these branches via git-flow actions which
we will describe below.
Getting started with git-flow
There’s a handy new addition to the toolbar in SourceTree (keyboard shortcut Cmd-Alt-F):
Based on the current state of the repository, the Git-flow button will
bring up a dialog with the most likely action you’d want to perform next. So if
you haven’t set up git-flow on this repo yet, it’ll help you do that by
default. If you’re on the development branch, it will default to starting a new
feature. If you’re already on a feature branch, it will offer to finish your
current feature and merge it back into the development branch, and so on. You
can always get to all the other git-flow actions via this button as
well, but most of the time the default option will be the action you’ll
want SourceTree to perform.
If you haven’t used git-flow already on this repository, the first thing
SourceTree will do is initialise your repository to use it. You’ll probably
just want to use the defaults in the initialisation window so that’s not
covered here. For more details please see the Help section included in SourceTree.
Next up, we’ll concentrate on the actions we can perform with Git-flow and
SourceTree.
Starting a feature
You can commit trivial changes directly to the development branch
(‘develop’) if you like, but any time you start on something non-trivial you
should explicitly start a new feature. This ‘Start
Feature’ action will be the default action when you click the Git-flow button
if you are currently on the dev branch.
The first thing to note is the ‘Preview’ window, which is present on all
of the action dialogs and shows you what will actually happen when you confirm
the dialog. In this case, a new feature branch called ‘feature/my-new-feature’
will be created (I used the default prefix when I initialised this repository).
You commit your feature implementations to this branch. If you want, you can
push the feature branch to your remote while you work on it (your team can
decide on whether that’s normal practice or not).
If at any time you want to switch branches, either to another feature
branch or to somewhere else, just use the normal mechanisms in SourceTree to do
that, such as double-clicking a log entry or a branch in the sidebar. Git-flow
determines your context simply from the branch you currently have checked out,
so it’s fine to jump around if you like.
Finishing a feature
Eventually when you’re done implementing a feature, use the ‘Finish
Feature’ action (again, this will be the default action from the toolbar button
if you’re on a feature branch):
Again, the Preview shows you what will happen — the feature branch will
merge into the main development branch, essentially queueing it for inclusion
in the next release. Feature branches are deleted by default but you can opt to
retain them if you like.
Starting a release
You start a release branch when you want to start preparing a new
release, which probably coincides with a feature freeze. Accessing the Start
Release option –either from the menu or from the toolbar action selection
window — brings up the following dialog:
The preview shows that a new release branch will be created. Most of the
time, you want to start the release from the latest commit in the development
branch, but you can choose to base it on another commit if you wish. This
essentially freezes the release, so it’s not affected by subsequent
development. You can also perform preparatory tasks for the release process on
this branch, such as updating the version number in source files, updating
changelogs, or committing other tweaks. Once these tweaks are done, you can finish
the release as described below.
Finishing a release
Once all the adjustments required for the release are done and
committed, you can conclude the release process.If you’re on the release branch
already, the git-flow button will show you the following dialog:
The preview illustrates that the release branch will be merged into the
production branch (‘master’ or ‘default’ normally) to indicate an update to the
deployed version. Sourcetree will also create a tag here for the release. The
release branch changes will also merge back into the development branch to make
sure the develop branch is kept up to date.
Starting a hotfix(Service
Pack)
What if you need to just fix a bug on the latest release? You don’t want
to create a new release, because that will pick up the recent changes from the
development branch. So instead, you can start a hot fix:
Hot fixes always start from the latest production code from the ‘master’
branch. Other than that, they’re basically the same as release branches.
Moreover, when you’re finished with the hot-fix, they behave the same way as
finishing a release branch. The changes are merged back into both the
production branch and the development branch, and a tag is created on the
production branch for the hot fix release.
Reference taken from :- https://blog.sourcetreeapp.com
Comments
Post a Comment