A better Git Flow for Unity development

After being introduced to this article by Vincent Driessen, I realized how chaotic my personal VCS is. I did not have an established process for branching, merging, and releasing, and that made self-development a bit of a nightmare, especially when I was working on Unity projects, and it got only worse when it came to collaborating. So after I bit of research, I decided to write my own variant of Git Flow for Unity development.

Short version

Three main branches with infinite lifetime : release, main and develop.
Two main branches with finite lifetime : hotfix and feature.

Branch of develop -> Create the feature -> merge it back into develop when finished -> For weekly builds, merge from develop to main -> For public releases, merge from main to release

Details

The development process in separated in multiple branches (from left to right, color coded) :

–Release–
The release branch, is for public releases. It must be always tagged with a version number, and contain thoroughly tested code. Except from the first release, it should always contain release notes. Commits come from the main branch. Builds from release must contain no bugs and offer the full experience of the current state of the project.

–Main–
The main branch is for short-term versions that should be thoroughly tested, and iterated from. It is merged from develop, and merged back to develop when the version is ready to be released. Every commit on develop must contain deployable code with no errors.

–Hotfix–
Ideally, every commit on main should be free of bugs, and contain deployable code. Sadly, things don’t always go as planned, and bugs are found after merge. This is what the hotfix branch is for. It branches from main, apply the fix, and merge back to main. It is not merged to release, and is not merged back to develop. It should follow the naming convention of hotfix/<bug>. The last commit before merging back into main should describe the changes accurately.

–Develop–
The main branch, where most of the work is done. Every task that is not a complete feature is done on develop. Features branches must branch from here, and merge back to it when the feature is done. Every commit on develop should contain deployable code with no critical errors. This model allows for a continuous development process, and allows for a quick iteration of a feature, as well as parallel feature development and easy collaboration with other developers.

–Feature–
A feature branch is a branch that contains a single feature. It is created from develop, and merged back to develop when the feature is done. It follows the naming convention of feature/<feature name>.

note : none of the branches are special on the technical level or use under-the-hood git tools. They are regular plain git branches.

Setup

While creating the repository, change the default branch to develop. This is not a critical step, but allows for a cleaner start, as the first commits usually contain the initial setup.
During or just after repository initialization, I recommend creating a .gitignore file for cleaner git history.
Then, create the following branches : develop, main, release.
Start working on develop branch.

Final notes and tips

As feature branches are very self-contained and have their content merged to develop, they don’t have to be remotely tracked, and can stay local to one developer to keep the remote as clean as possible.
As a git management tool, I find VSCode sufficient for all my needs. I could write an entire article about how I use VSCode for everything (including writing these lines !), but here I will just recommend my favourite git-related extensions. It is worth noting that it has VCS support built-in, but the extensions will improve the ease of use.
- The Gitlens can do pretty much everything a modern git GUI can do. (in fact, it is made by the Gitkraken people! Thanks !)
- I find visuals and graphs very helpful, so I check GitGraph obsessively. It is a nice extension that allows you to see the evolution of your commits, and it is also a great way to visualize the evolution of your branches.
Yes I am aware of git-flow, but I prefer combining this granular level of control with visuals and graphs !
This is only my way of doing things ! I have yet to test this with a larger team, and I am not sure if it will work for everyone. If you have feedback, questions, or truly, even if you just want to say hi, please reach out !

Bibliography :

Questions, remarks or feedback? Reach out!
Comments are not published.