During the last TSC meeting we discussed about reviewing the branching model used for our projects.
Here we'll be describing how the model we (Marco and I) mentioned works and its peculiarities.
Note: to simplify our lives we will use the commands pre Git v2.23.0 (git switch
and git restore
aren't that used yet).
In this model we operate with the main development line (master
) and release branches (e.g. 1.0.x
, 1.1.x
, 1.2.x
).
This provides a lot of flexibility whilst keeping a single workflow.
This depends on the needs of the project.
For the simple ones, we branch-off master
and merge things back to master
:
Other projects might need multiple development lines.
An example is Doctrine ORM that has 2.8.x
as the development line for simple features and deprecation notices and master
for the next major release (3.x-dev
).
As you can imagine this is more complex since the features are implemented targeting the specific development lines (and syncronised to master
):
Some projects only offer active maintainance for the latest supported version, which simplifies things quite a lot.
In this scenario we'd only need to apply fixes for bugs for the latest release branch (then syncronised it with master
):
If we do need to have maintaince of older versions, the fixes should be applied on the version which introduced the issue (then syncronised all way to master
):
TBD
To keep branches synchronised we use merge-ups.
That consists in getting the changes of a specific released branch merged all the way up to master
.
This ensures that all release branches and the master
branch are up-to-date and will never present a bug which has already been fixed.
Example
Let's say we've released the versions 1.0.0
and 1.1.0
.
New features are being developed on master
(1.2.x-dev
).
After a couple weeks, a bug was found on version 1.0.0
.
The fix for that bug should be done based on the branch 1.0.x
and, once merged, the branches should be updated in this way:
- Create a branch from the fixed
1.0.x
(git checkout 1.0.x && git checkout -b merge-up/1.0.x-into-1.1.x
) - Create a PR using
1.1.x
as destination - Create a branch from the fixed
1.1.x
(git checkout 1.1.x && git checkout -b merge-up/1.1.x-into-master
) - Create a PR using
master
as destination
- Checkout to merge-up branch (
git checkout -b merge-up/1.1.x-into-master
) - Sync merge-up branch (
git merge --no-ff origin/master
) - Solve conflicts (using
git mergetool
or through an IDE) - Resume merge (
git merge --continue
) - Push (
git push
)