The Working development and Feature development Branches

Working development branch

The development branch is the latest compilable code. It’s like a nightly build.

When the development branch is tested stable, we can then fast-forward the production branch into it.

Use git merge with --no-ff

When we merge and fast-forward the stable production branch into a development branch, we may choose to merge with the option --no-ff. The no-ff option stands for “no fast-forward.”

This means that even the stable branch can be fast-forwarded. We still want to create a new commit object. In such a case, when we git log the graph, we can always see that it’s merged with two parent nodes.

This practice allows us to log when and where the main production branch has moved. For example, given the following commit log, the development branch is ready for production.

* 60c1acd (HEAD -> development) Complete feature B and tested.
* 4a4571e Kick start feature B.
* 8006e3e (production) Merge feature A.
* 31666e2 Complete feature A.
* b0d3c42 Init the example project.

If we switch to the production branch and merge the development branch, we lose where the production branch was.

 $ git switch production
 $ git merge development

The git log becomes the following, and we lose which commit production was pointing to before the merge.

* 60c1acd (HEAD -> production, development) Complete feature B and
tested.
* 4a4571e Kick start feature B.
* 8006e3e Merge feature A.
* 31666e2 Complete feature A.
* b0d3c42 Init the example project.

Instead, if we use -no-ff as follows, we create a new branch that merges the development branch.

 $ git switch production
 $ git merge --no-ff development

Now, we see the following commit log:

*   ebb4f0f (HEAD -> production) Merge branch 'development'
|\
| * 60c1acd (development) Complete feature B and tested.
| * 4a4571e Kick start feature B.
|/
* 8006e3e Merge feature A.
* 31666e2 Complete feature A.
* b0d3c42 Init the example project.

Feature development branch

We kick-start new feature implementation based on the development branch. If $n$ features are implemented at the same time, we can have $n$ feature branches ongoing. These branches are finally merged into the development branch if we want to keep the implementation.

Each feature branch is responsible for a single feature.

Under each feature branch, we’re free to create as many subbranches as we like. These branches are treated as experiments on specific features.

For example, given a feature requirement, there could be more than one way to solve the problem. And sometimes, we don’t know which one is better until we do some experimentation. Creating branches allows us to extend the code in several very different directions.

After we finish the experimentation, we can delete the unused branch using git reset. Then, we can clean up the code and have a final check before merging the code into the development branch.