Feature branch development and continuous integration

Martin Fowler
Recently, I used the distributed version control tool (mercurial/GIT) and wrote a blog post titled "feature branch ".
This article mainly discusses three ways to work after using the distributed version control tool. (I really admire Martin Fowler's ability to sum up .)

 

1. Stacked changes, deferred merger

 

In my opinion, this method does make full use of the flexibility of DVCs, but it is clear that developers who do not like to submit frequently may continue to develop this bad habit.

 

2. Keep the main line of code and frequently submit it to the main line

 

 

 

In this case, you still inherit the centralized version control tool (CVCs) development method. Because DVCs provides a history of local changes for each user, it is easy to use the personal build practice, which improves the development efficiency and the chance of successful build in the Team's continuous integration environment.

 

3.Promiscuous Integration

 

Obviously, in this case, the communication between the two branches is very full, but the communication with the main line is basically one-way communication. Martin Fowler also pointed out that at this time, the developers on the two branches had fully communicated in advance (went out for a drink together )".

 

The second and third types may have no absolute difference between good and bad. For a normal development process, I will select the second one (this is the main method used in the development process of the current cruise team); For Spike, the third method is also good (it is also frequently used by the cruise developers, but it will not last for too long each time, otherwise the large merge problem will occur when merging with mainline ).

 

And,I seriously agree that "Ci is a valid communication tool" unless the development team does not submit it frequently.