Hi all,
What do you think of the following?
Suggested (types of) branches:
Feature branches: 0…n - one for each ‘feature developer’
Merge-and-test branch: 1 - for merging and testing new features before pushing to the master branch
Master branch: 1 - for feature developers to pull from (to base their features on), and possibly to use for builds/releases
Example:
All feature developers pull the most recent master branch when starting work on a new feature.
Developer 1 works on his own local feature branch FB1
Developer 2 works on his own local feature branch FB2
Developer 3 works on his own local feature branch FB3
When Developer 1 has finished his feature, he pushes this to the remote feature branch FB1
When Developer 3 has finished his feature, he pushes this to the remote feature branch FB3
The person in charge of merging, manually merges the changes from the feature branches (FB1 and FB3) to the ‘merge-and-test’ branch and makes sure that all changes work together properly. If none of the existing functionality is broken by these merges, and the new features also work as expected, he merges the ‘merge-and-test’ to the master branch. Obviously we could have a small group of people in charge of the merge-and-test and the master branch, and the frequency is something that has to be discussed.
[HR][/HR]
This means that we would always have at least 1 perfectly working branch which everyone can use as a starting point, the master branch.
I think that this has a couple of implications:
-
Testing that all changes work together properly will be a lot of work as the number of features increases. I think we have to find a way to automate this as much as possible. I’ve read that UE(4) supports unit tests and feature tests for C++ code. It would be cool if this is also supported in blueprints. If this isn’t supported in the ‘blueprint visual scripting language’, I expect that it should be possible to write tests in C++ for blueprints. If every feature developer has tests accompany their feature it should be easy to test it when it’s integrated with the rest. We should also add all new feature tests to our regression test set for future merges.
-
In the example above, you might have noticed that Developer 2 didn’t finish his feature before it was merged with the ‘merge-and-test’ branch. If he misses a couple more merges and keeps working based on an ancient master branch, he might get too far behind for (parts of) his feature to work at all when integrated with the rest of the project, he might have to start again or at least redo some stuff. So you shouldn’t stay too far behind, either by working faster, splitting up the feature into smaller pieces, or by updating your local master branch when you notice there’s a new one available.
[HR][/HR]
I think we should be able to work with the Atlassian source tree for this, should help visualize which Feature branches are ready to be integrated and when they have last been integrated etc.
Talking about visualizing…:
