Table of Contents
Workflow
Based on http://nvie.com/git-model
Overview
- Topic Branches (Or Feature, or short-lived) are branches you temporary create for a specific issue/feature, most of the time you keep them local.
- Long Running Branches are branches that for example denote the different levels of stability/experimentation. E.g master (stable), development (ongoing development). These are usually remote.
- develop: main develop trunk; latest development version
- feature/*: local / custom user branch(es) to code new features, issue fixes, etc
- release/*: release preparation branches
- stable (master, in the picture below): end user, milestone versions
General
RULE #1: Don't commit to the stable branch, as the remote repository will not accept the push.
Ongoing development happens in the develop branch.
Work inside a feature branch. You can also publish it, incase you need to work with more people on it, or need your work backed up (useful with longer running).
When sufficiently finished, merge the feature branch back into the develop branch.
Managers will merge the develop branch to stable (through a release branch) as soon as the next milestone release is ready.
Working
Please see Setup below for first time setup/configuration.
note: You can easily access your repository in a command prompt inside Git Extensions -> Git Bash (2nd icon to the left of Filter)
- Pull latest from develop branch (git pull)
- Create a feature branch (or fix/issue etc.):
git flow feature start somefeature(More examples: issue6750 or sys_attachments_improvements or geardialog-improvements)
- Start your work
(NOTE: If this work is going to take longer than a day, it is recommended you make proper backups from your repository/work. Pushing the feature branch to remote is possible too, however, rebasing is then strictly prohibited!) - Commit your work step by step (This is the major improvement over previous model)
- Optionally merge the latest develop branch or rebase on it, and repeat work+commit.
git merge develop or git rebase develop - When finished, merge your work back to develop branch:
git flow feature finish somefeature
- (or delete the branch incase you don't want to use the result)
- If there are any merge conflicts, solve them, follow instructions from git flow
- When successful, git pull and git push to push your changes to the online repository
You can track someone else's feature, if they have published it.
It is very important that you use git flow for this, as for instance Git Extensions, will cut off "feature/", which could mean you create a new branch when pushing things back.
git flow feature track <name>
Publishing a feature to remote repository (Remember, may not rebase anymore if you do!):
git flow feature publish <name>
Easy diff’ing of all changes on a specific (or the current) feature branch:
git flow feature diff [feature]
Feature branch rebasing:
git flow feature rebase
This is the end section for developers.
Releasing Ongoing Development Updates
The following is for managers.
- Pull latest from develop
- Buildtest, create a feature branch incase of issues, merge back to the develop branch once completed.
- Release through six-arma-builder
- Push changes back to origin/develop.
Releasing Milestones
The following is for managers.
- Pull latest from develop
- Create release branch:
git flow release start '1.1.10'
- Bump the version number
- Do final fixups and tests.
- When finished, merge the release back to develop and stable branch:
git flow release finish '1.1.10'
Hotfixing
The following is for managers.
Incase of severe issues, we might want to hotfix a Milestone release.
- Pull latest from stable branch
- Create hotfix branch:
git flow hotfix start '1.1.12'
- Apply fixes (commit)
- Test
- When finished, merge the hotfix back to develop and stable branch:
git flow hotfix finish '1.1.12'
Setup
Git
Download Binaries and Dependencies zip files (not setup) and install getopt.exe from the util-linux package into C:\Program Files\Git\local\bin. (Only getopt.exe, the others util-linux files are not used). Also install libintl3.dll from the Dependencies package, into the same directory.
Clone the git-flow sources from GitHub:
$ git clone --recursive git://github.com/nvie/gitflow.git
$ cd gitflow
If using a GUI without a recursive option for cloning, make sure to update all submodules. This should populate the shFlags directory.
Optionally, download slightly modified msysgit-install.cmd (installs to local/bin, adds pause for reading output)
Run the msysgit-install script from a command-line prompt (you may have to run it with "Full Administrator" rights if you installed msysgit with its installer):
C:\gitflow> contrib\msysgit-install.cmd
Repository
If you have the original ACE git repository, please follow a).
For new clones, please see b).
a) Conversion
- Commit your open work to master, or remove all open changes.
This branch will not be useful anymore later, but it will remain until you delete it (after you've exported your changes etc.) - Git pull
- Setup the new tracking branches and prune old ones:
git checkout --track -b stable origin/stable
git checkout --track -b develop origin/develop
git remote prune origin
- Reapply your open work if you had any.
- Delete any dead branches, like master:
- List the branches in a work folder using "git branch -a"
- Delete the unwanted ones using "git branch -d nameofbranch"
- See below how to enable gitflow.
b) Cloning
- Clone the repository, setup stable branch tracking.
git clone git@git.dev-heaven.net:ace.git cd ace git checkout --track -b stable origin/stable git checkout develop
See below how to enable gitflow.
Enable gitflow
- Inside the repository:
git flow init
Production branch -> stable (The rest all default (enter). Development branch -> develop)
Rebase Notes
- Use Rebase inside your local branches to rebase your work on top of the latest develop branch (incase there have been changes.
This will ensure (once you want to merge it to the develop branch) your merge will be without conflicts, aswell as allows you to work with the latest source, inside your topic branch. - Never use Rebase on remote branches. Or never rebase commits that have been received by servers/other devs.
- If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.
Sources
- http://nvie.com/git-model
- http://progit.org/book/ch3-4.html
- http://progit.org/book/ch3-5.html
- http://progit.org/book/ch3-6.html
- http://gitguru.com/2009/02/03/rebase-v-merge-in-git/
Next subject, Creating working patches: Patching
Note to self: Need to block merges or pushes alltogether on the stable branch. (and master, just to prevent users from recreating it :P)