Pure-Python implementation of Git extensions to provide high-level repository operations for Vincent Driessen's branching model.
We've added a few tweaks to make it cooperate with Pivotal Tracker, Review Board and Jenkins.
For the best introduction to get started with git flow, please read
Jeff Kreeftmeijer's blog post http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow.
Or have a look at one of these screen casts:
- How to use a scalable Git branching model called git-flow (by Build a Module)
- A short introduction to git-flow (by Mark Derricutt)
- On the path with git-flow (by Dave Bock)
Salsita GitFlow basically follows the same guidelines, it just interacts with some other tools as well. Features are tied to Pivotal Tracker stories and Review Board review requests, so:
feature startlets you choose a Pivotal Tracker story to be started.feature finishfinishes the PT story and posts the feature diff into Review Board. You can callfeature finishmultiple times and it will detect existing review request and update it. Every time you runfeature finish, the assocciated Jenkins doploy job is triggered and the develop branch is deployed to the develop environment.release startadds labels to the currently finished Pivotal Tracker stories, thus assigning them to the release of your choice. The newly created release branch is deployed to the QA environment so that it can be tested.release finishchecks if all the relevant stories have been reviewed and QA'd and if that is the case, the release branch is deployed to the QA environment to be tested. The release branch is deployed into the client environment so that the PT stories can be tested and accepted by the client.release deliverchecks if all the relevant stories were accepted by the client and if that is the case, the release is finished and closed, i.e. all the branches are merged and review requests submitted. The project is then deployed to the production environment.
You can install salsita gitflow, using:
pip install salsita-gitflow
Or, if you'd like to use easy_install instead:
easy_install salsita-gitflow
salsita-gitflow requires Python 2.7.
Global (same for all projects):
* git config --global reviewboard.url https://example.com/rb/ (the trailing slash is REQUIRED) * git config --global reviewboard.server https://example.com/rb/ * git config --global gitflow.pt.token 12345678910
You will be prompted for the project-specific settings during git flow init or other commands when the need arises.
If you have the original git-flow <https://github.com/nvie/gitflow> installed, just go to the git bin folder and delete everything that starts with git-flow.
For those who use the Bash or ZSH shell, please check out the excellent work on the git-flow-completion project by bobthecow. It offers tab-completion for all git-flow subcommands and branch names.
Please note that some subcommands have changed in this gitflow fork, so it is questionable if the completions still make sense.
This project is still under development. Feedback and suggestions are very welcome and I encourage you to use the Issues list on Github to provide that feedback.
Feel free to fork this repo and to commit your additions. For a list of all contributors, please see the :file:`AUTHORS.txt`.
You will need :module:`unittest2` to run the tests (which are completely broken as of now, so nevermind).
If you want to install salsita-gitflow from the develop or a release branch, follow these steps:
- Use virtualenv to create the testing environment.
- Once the environment is activated, get the sources:
git clone https://github.com/salsita/gitflow.gitgit checkout developorgit checkout release/X.Y.Zpython setup.py install- The git flow commands should be available to you now, just make sure you are using the right one (
man which)
git-flow is published under the liberal terms of the BSD License, see the :file:`LICENSE.txt`. Although the BSD License does not require you to share any modifications you make to the source code, you are very much encouraged and invited to contribute back your modifications to the community, preferably in a Github fork, of course.
Before you start, make sure that you are using SSH for communication with origin.
To initialize a new repo with the basic branch structure, use:
git flow init [-d]
This will then interactively prompt you with some questions like what branches you would like to use as development and production branches, and how you would like your prefixes be named. You may simply press Return on any of those questions to accept the (sane) default suggestions.
The -d flag will accept all defaults.
Note: Please use the -d flag it will make your life much easier.
init will also check your git config to see if the required records for Review Board and Pivotal Tracker are in place, failing if that is not the case.
The list of command line flags listed here is not complete. Check the wiki for a more complete list. The best documentation is, however,:
git flow <subcmd> <subsubcmd> -h
To list/start/finish feature branches, use:
git flow feature git flow feature start [--for-release RELEASE] git flow feature finish [<name>]
feature startwill list unstarted & started stories from current & backlog iterations in Pivotal Tracker. Select one and its state will change to started. This command creates a feature branch as well, so switch between stories usinggit checkout, notgit flow feature start. If you wish to base your story on a release branch, use--for-release RELEASE. This will also assign the story in Pivotal Tracker as a part of starting it.feature finishwill finish the currently active story (merge it into develop, push develop, change the story state in PT to finished and post a review request to Pivotal Tracker). It will do its best to find the corersponding review request in ReviewBoard and update the review but if it can't then it will post a new review. You can force posting a new review by setting the-n/--new-reviewflag.To push/pull a feature branch to the remote repository, use:
git flow feature publish <name> git flow feature pull <remote> <name>
To list/start/deploy/finish release branches, use:
git flow release git flow release start [-D|--no-deploy] <major.minor.release> [<base>] git flow release finish [-R|--ignore-missing-reviews] [<major.minor.release>]
release startwill by default access Jenkins and it will trigger the deployment job paired with your project. No need to set up any git config manually, you will be prompted at run time.If the Jenkins deployment job or the QA environment for your project is not r 7796 eady or is not being used, you can use
-Dor--no-deployto tellrelease startnot to access Jenkins at all.For
release finish, if you are not using Review Board for your project, you can use-Ror--ignore-missing-reviewsto skip the reviews check while doing a release.To list/start/finish hotfix branches (not supported by Salsita), use:
git flow hotfix git flow hotfix start <release> [<base>] git flow hotfix finish <release>
To list/start support branches (not supported by Salsita), use:
git flow support git flow support start <release> <base>
For support branches, the
<base>arg must be a commit onmaster.
There is one more subcommand that does not really fit into the original GitFlow.
It is git flow deploy. It is invoked by release start|finish|deliver
automatically, but you can as well trigger deployment separately by typing:
git flow deploy develop
git flow deploy release <version> {qa,staging}
git flow deploy master
Only the release version accepts additional parameters since the other two forms imply what branch and what environment to use.
A small demo how a complete feature implementation could look like:
$ git config --global reviewboard.server https://example.com/rb/ $ git config --global reviewboard.url https://example.com/rb/ $ git config --global workflow.token 0123456789 $ mkdir project $ cd project $ git remote add origin git@github.com:salsita/project.git $ git pull $ git flow init -d # Pick the project from PT and the repo from RB. $ git checkout develop $ git flow feature start # Pick the story from PT. # Code code code $ git add * $ git commit -s # Enter a beautiful and descriptive commit message. $ git flow feature finish # Go to the Review Board to submit the generated review request. # PROFIT!
gitflow was originally developed by Vincent Driessen as a set of
shell-scripts. In Juni 2007 he started a Python rewrite but did not
finish it. In February 2012 Hartmut Goebel started completing the
Python rewrite and asked Vincent to pull his changes. But in June 2012
Vincent closed the pull-request and deleted his python-rewrite
branch. So Hartmut decided to release the Python rewrite on his own.
Of course, the best way to show your appreciation for the git-flow
tool itself remains contributing to the community. If you'd like to
show your appreciation in another way, however, consider donating
to the original authors through PayPal:
