Guest Post by Kem Tekinay, a consultant and developer based in New York. Kem has been an avid Xojo user since the early days and is a world-renowned thinker and philosopher, at least its his own mind. You can find him and his works through the MacTechnologies Consulting web site.
After months of work, your project is so fabulous that you need more developers. You’ve been using Git as your version control system and creating/merging branches to keep it all straight, but so far it’s just been for personal use. How do you coordinate with others to maintain some semblance of order?
Try the Gitflow Workflow.
Gitflow
Gitflow is a popular way of managing revisions centered around a few basic ideas and actions. It is built into recent version of Git and supported by clients like the free SourceTree and the commercial Tower apps.
You start Gitflow with two main branches, master and develop. These are initialized for you when you activate Gitflow through one of the gui apps or through the command line.
The master branch is never modified directly. It is the code for the currently released version of the app and it is only updated on a new release.
The develop branch is never modified directly either. It starts as a branch of the current master and is updated with changes made in other branches (feature or hotfix, see below). The key here is that the develop branch should always be in a state where it can become the new master at a moment’s notice.
Gitflow is then concerned with the actions that we developers might take. The first common action is to start a “feature”. This feature branch should be appropriately named, e.g., “Addinvoicequerywindow”, and is usually branched off of develop, although it can start from any commit or branch. The developer works in this branch to add and test their code, committing as necessary. Once complete, they “finish” the feature by choosing “Finish” from the Gitflow options. Gitflow merges the feature branch into develop and optionally deletes the branch.
Each developer can have as many simultaneous features as needed and can manually merge one feature branch into another, or cherry pick changes from any other branch.
The next action that a developer might need is a “hotfix”. By starting a hotfix branch, Gitflow will branch off of master, not develop. The purpose of a hotfix is to correct a bug that came up in the currently released version that cannot wait for the next full release. Once a hotfix is “finished”, Gitflow will merge it back into both master and develop. At that point, the new master should be compiled and released.
The final action is the “release”, started after all the needed features have been merged into develop and are ready to be deployed. This is where you can make final changes like updating the version number, release notes, etc. When a release is “finished”, Gitflow will merge it into master and develop, and tag that branch with the version number. After that, the next cycle begins.
In short, you start a feature (or features), make it work, then finish the feature. When all your features are done, start a release, update version numbers, etc., and finish the release. If a bug in the currently deployed version comes to light, start a hotfix, fix the bug, then finish it. By using “start” and “finish” through Gitflow, it handles the appropriate branching, merging, and tagging for you.
For more information, go to the Atlassian site for a good general description and examples (scroll down on the site to read about Gitflow).
