Every project needs a workflow
There are various types of git workflows out there, and a lot of arguments over which one is "superior" to the others. However, they all have different usage cases, and mostly depend on the preferences and habits of teams. We will be using our own workflow, which is somewhat of a hybrid between the One Flow and Git Flow models.
Getting started with Yuuto flow
Before we get into reviewing the workflow, it is crucial that you already understand the branching concept in git. All that follows is based on these concepts of branching, so if you aren't really sure what that is, check this out.
The goal of Yuuto flow is to maintain high standards of quality and
stability of the deployed bot, as it should integrate seamlessly
with the campers and daily activities in the server. The
master branch is where deployed code for Yuuto is
located on, therefore all code in the master branch
should be rigorously tested and deployable. Should anybody want to
host their own copy of Yuuto, master is where they
should pull it from.
All code in the master branch should be rigorously
tested and deployable.
If master has to contain pre-tested code, another long
term branch is needed to contain the pre-production code. This
branch is known as develop and is where all new
implementations and features get combined for testing before
production. In turn, develop implements code from
feature branches, which is where most of the action and
new additions are being worked on.
Feature branches
Feature branches are where the fun happens. This where developers
will work alone or in smaller teams and develop new features for the
bot. The branches are based on the develop branch, and
once completed, are merged back via pull requests.
Feature branches can be created by anyone, and should always be
started from the latest version of develop. These
branches should reside under the feature branch folder,
and have a descriptive name. Before starting a
feature branch, check with other developers to make
sure nobody else is already working on such feature.
Procedure
# Initial creation
$ git checkout -b feature/f-name develop
# When ready to merge back
$ git push origin feature/f-name
After the feature has been pushed to remote, open up a pull request
to merge to develop. Work out any fixes until the PR is
approved (2 reviews). Release branches are squashed and then merged.
Once the feature branch has been integrated, don't forget to delete
it.
Develop
The brain of the whole operation. This is the branch that contains
the mishmash of code, and is used to check how all different pieces
work together before deploying it. Features branch out of it, and
merge back in it. Releases are also based on specific commits to the
develop branch.
One shouldn't commit to develop directly, as both
features and hotfixes flow into it from the
sides. Once an update is deployed to master,
develop gets also updated with the latest code from
master, while keeping advancements in other areas. That's the goal
of develop: test code and continue work without impacting release
cycles.
Master
The master branch follows a simple, yet very important
rule: all code in it should be bug-free and deployable. Anybody
wishing to obtain a stable and working copy of Yuuto, should clone
from this branch.
Code should never be committed to master directly.
Instead, code will be integrated to it from a
release branch via pull requests. Why not from
develop directly? For the very simple reason that
develop should not be limited by the progress being
made on master. Development and features can continue
to be added even if review or changes fro deployment take longer
than expected.
Once master has received its update,
develop branch is updated and rebased on top of the
latest release, and work continues.
Release branches
Before code is deployed to master, it goes through a
release branch. The branches are created when preparing
for a release, and deleted once a release has been finalised. Their
sole purpose is not to hinder development, as described in the
master section.
Releases are created off the develop branch, and
anybody can start a release branch. Once they are
created, only minor polishes should be made to it, to prepare for
smooth release integration via pull requests. All
release branches should go under the
release folder, and once ready to be released, they
should be tagged with the
release number.
Release branches can be initiated from the current stage of develop, or from a specific commit, in which case use the hash corresponding to the particular commit when creating a branch.
Procedure
# Initial creation
$ git checkout -b release/v-number develop-hash // hash is optional
# When ready to release
$ git tag v-number // tag release with version number
$ git push --tags origin release/v-number
After the release has been pushed to remote with the appropriate
tag, open up a pull request to merge to master. Release
branches are squashed and then merged. Once the release branch has
been integrated, don't forget to delete it.
Hotfix branches
Sometimes we screw up. When we do, we need to fix the issues.
Hotfixes are needed to fix things when the original branch has
already been deleted, such as features or releases. Hopefully, if
needed, they will be implemented to develop, however if
the issue impacts master or releases have been started,
the hotfix will first be applied to master, and
develop will get the fix when it gets the latest
updates from master.
Multiple hotfixes may happen concurrently, there may be pending
hotfixes for both master and develop.
Which branch(es) to apply the hotfix to will depend on the issue
needing to be fixed. A feature hotfix can live together with a
deployment hotfix, thus each hotfix should serve the purpose of
fixing only one issue at a time.
Hotfixes should make use of tags if they are applied to
master, in which case they follow the same procedure as
release branches do. They are
implemented via squash and merge pull-requests and deleted after
integration.