Discuss: how to develop new feature in separated branch

There are three purposes for developing new features in a separate branch:

  1. Guarantee the quality of the master branch
    The quality of our master branch is always poor, which to a certain extent also leads to the poor quality of each new version we release. In issues, we can often see that there are many bugs related to non-GA features. I think this is not appropriate.
    New features, fully tested in a separate branch, and then merged into the master branch. In the most ideal case, our master branch can be released at any time.

  2. Improve development efficiency
    To develop a new feature, a lot of time is spent fixing bugs. Develop in a separate branch can test faster and fix bugs faster.
    For example, some functions have been developed, and corresponding tests (not simple unit-tests, but more systematic tests) are also ready. The original logic needs to be reviewed first, and then tested after merging, which requires a long time to wait.
    In the development of a separate branch, we can quickly merge the code for testing, while reviewing the code. In addition, it is much more convenient to fix bugs in a separate branch. Depending on sufficient test cases, we can fix bugs in batches and add test cases.

  3. Flexible delivery
    We are now using the train-catching model, which requires us to get on the train atomically. After the development in the separate branch, the test is completed, the conflict resolution is completed, and the review is completed, up to this step, there are no changes to the master branch. In that case, the time to get on the train will be quick.
    If you develop on the master, but find that the sprint cannot be completed/tested, then you can only add switch/experimental features.

At present, there are several main concerns:

  1. Trouble with conflict resolution
    There are already methods in this area, you can merge the refactored code into the master first, and then develop based on the refactored part.

  2. Feature compatibility issues
    The owner of this feature needs to consider the compatibility issues carefully when planning the feature, including when designing and testing.

In general, I think the advantages of developing features in a separate branch outweigh the disadvantages, and it is also a key way to truly improve the quality of TiDB. I used this method in the development of CTE before, although it is not the best practice, but I can feel its benefits. If you want to try this development method, I can do my best to help you.


Hi @wjhuang2016 thanks for your sharing! It is a good example of best practices developing a feature, as we ever discussed.

I moved this topic to general category as you can see its usage, meta category is for the forum itself, I’ll try to find a better name to distinguish.

Besides, this topic is more like a best practice sharing than a proposal to be adopted in the community. As it is a proposal, do you want it to be formally documented in our development guide?

No, this development style is at the very early stage and isn’t accepted by everyone.
I want more and more people to try it and overcome its disadvantages.
Maybe proposal isn’t a good name for this topic.

@wjhuang2016 I’m going to apply feature branch pattern with this issue

that we cannot migrate the whole pkg in one PR, as well as we dismiss the goleaks due to complex historical leaks

with offline discussion I think @zhouqiang-cl are also working on a community native CI service for smooth coordination on feature branch.

Let’s see whether feature branch a good pattern :slight_smile:

so if there is a feature named feature-1, there will be a long term branch named featrue-1 in pingcap main repo? it lasts in main repo until it is finished and merged to main repo?

and me as a contributor, if i want to contribute to sub issue of feature 1, i need checkout a branch sub-issue-of-feature-1 from feature-1 from my cloned repo, work on it, then after finish, make pull request to merge it to feature-1 branch of main repo?

in other words, the influence to contributor is that, he/she needs to know the issue belongs to which feature, so he/she can checkout from it and merge back to it?