Many teams have already migrated to git and many more are transitioning to it now. Apart from training single developers and appointing Champions to help with the adoption it is imperative to pick a nice and simple code collaboration practice that does not complicate things too much. With git one can definitely conjure very complicated workflows, I’ve seen them first hand. A manual on workflows does not come pre-installed with git, but maybe it should seeing how many people have questions on the topic. The good news is that we’re working hard to write material that helps. Recent webinars and guides on workflows If you prefer reading and pretty pictures, one of the most popular sections of our git tutorial site is the workflows section: But before you leave for those destinations please read on, because I have something really cool for you. I want to detail a terse but complete description of a simple workflow for continuous delivery. The prerequisite is that you and your team are at least a little bit acquainted with git, and have good knowledge of the rebase command in the two forms (interactive and not). A basic basic branching workflow for continuous delivery The simple workflow I want to describe has two guiding principles: master is always production-like and deployable. rebase during feature development, explicit (non fast-forward) merge when done. Pulling change-sets using rebase rewrites the history of the branch you’re working on and keeps your changes on top. The rebase you want in this workflow is the one in the second picture. Armed with these guiding principles let’s breakdown the seven steps: 1. Start by pulling down the latest changes from master This is done easily with the common git commands: 123git checkout master git fetch origin git merge master I like to be more explicit and use fetch/merge but the two commands are equivalent to: git pull origin master. 2. Branch off to isolate the feature or bug-fix work in a branch Now create a branch for the feature or bug-fix: 1git checkout -b PRJ-123-awesome-feature The branch name structure I show here is just the one we use, but you can pick any convention you feel comfortable with. 3. Now you can work on the feature Work on the feature as long as needed. Make sure your commits are meaningful and do not cluster separate changes together. 4. To keep your feature branch fresh and up to date with the latest changes in master, use rebase Every once in a while during the development update the feature branch with the latest changes in master. You can do this with: 12git fetch origin git rebase origin/master In the (somewhat less common) case where other people are also working on the same shared remote feature branch, also rebase changes coming from it: 1git rebase origin/PRJ-123-awesome-feature At this point solve any conflicts that come out of the rebase. Resolving conflicts during the rebase allows you to have always clean merges at the end of the feature development. It also keeps your feature branch history clean and focused without spurious noise. 5. When ready for feedback push your branch remotely and create […]