My Git workflow

ArticleDirectory

• Initial usage
• Unstable production environment
• Speed is life
• Never mess up the master
• Summary

Friendbuy is an Internet startup company. ProductSource codeIt is hosted on GitHub. EC2 has three environments: production environment, test environment, and continuous integration environment. Basically, there are a large numberCodeSubmitted, tested, and deployed. After more than a year of integration, git's use process was gradually streamlined. However, this was not the case at the beginning. All developers have never used git, which is basically the background of SVN.

Initial usage

There is only one git branch, that is, the master. The Development Team directly submits new changes to the master. The deployment is actually executed in the production environment.

 
Git pull
 

The daily work of developers is also very simple.

 
Git pull -- rebase
Git commit-a-m "XXXX"
Git push
 

Basically, git is used as SVN.

Unstable production environment

Soon the problem occurred. The chain was dropped during a demonstration to the customer.

The boss is very upset and has doubts about the quality of production environment deployment.

In order to make the production environment stable, the team decided to sacrifice the timeliness, establish a more formal process, and add a test environment and an automatic integration environment.

The Code submitted each time is automatically integrated into the environment for testing.

It will be manually deployed to the test environment from time to time for testing.

The deployment to the production environment is decided only when the test environment is almost measured.

In addition, each time you deploy the service to the test environment and product environment, you will be tagged.

 
Git tag-a xxx-M XXX
 

 

Speed is life

As we all know, internet startups are playing at a speed. After such a set of processes is added, a feature will become very lengthy to publish.

The most terrible thing is that, in order to try different styles, the website often has a comprehensive revision. Every complete revision should coordinate resources from all aspects, especially a long UI adjustment process.

The problem is that when the website is partially revised, other features of the customer still need to respond, and the online bug of the product still needs to be fixed.

So there is a branch.

 
Git Branch New-retailer-site master
Git checkout New-retailer-site
# Change some thing
Git commit-a-m "XXX"
Git push origin New-retailer-site
 

After the branch is used up, it will be merged into the master.

 
Git checkout master
Git merge New-retailer-site
# Fix conflit
Git commit-a-m "XXX"
Git push
 

Finally, you can delete the branch.

 
Git push Origin: New-Retailer-site
 

 

Never mess up the master

In a very short time, the Branch was hit by two digits. We didn't care about branch management at the beginning.

Until such a thing occurs:

The Development Team unanimously decided that the new-retailer-site is almost ready for release. Then the new-retailer-site is merged into the master.

Then some other features are developed on the master.

However, the new-retailer-site UI cannot be satisfied. The development team was asked to release the "useful" feature in the master one day, and the style revision work was delayed.

This is hard to do, and all the changes have been mixed in the same branch.

The final solution is to use

Git log

I found out all the changes. Because the comparison was too troublesome, I wrote some code to do this.

 Def List_commits (Branch ):
Commits = Local ( '  Git log  ' + Branch + '  ^ Master -- no-merges -- format = format: % s, % H ' , Capture = true)
Commits = commits. Split ( '  \ N  ' )
 For Commit In Commits:
 Print ( '  ==>%S <==  ' % Commit. Split ( '  ,  ' ) [0])
Print ( '  Https://github.com/friendbuy/apps/commit/%s  ' % Commit. Split ( '  ,  ' ) [1])

Then extract the found commit in a line of cherry pick.

 
Git cherry-pick <commit ID>
 

For a long time, I am confused about which branch is the product deployment branch.

Until one day, the Team decided that it would no longer be able to merge irrelevant branches into the master.

The normal workflow should be to select the branch for candidate release, such as new-retailer-site.

 
Git checkout New-retailer-site
Git merge master
# Fix conflict
Git commit-a-m "merge"
Git push
 

Then, in the test environment

 
Git checkout New-retailer-site
Git pull
 

After the test is passed, confirm that the product can be released to the product environment.

 
Git checkout master
Git merge New-retailer-site
Git push
 

Update the remaining branches one by one

 
Git checkout feature-branch-1
Git merge master
#...
Git checkout feature-branch-2
Git merge master
#...
 

Summary

Using feature branch, you can develop many features at the same time and decide when to release the features. For example, during the Christmas period, basically no feature branch was released, but development was not stuck. In addition, the business priority is often adjusted, and half of the branches that are often developed will also be thrown away.

When using multi-branch development, you must maintain a master branch always corresponds to the "code that will be released to the product environment", and keep the master as the center for consistent merging, otherwise, it will be difficult to manage branches in disorder.

At present, there is a defect that the continuous integration environment only tests the master. Ideally, a staging branch should be established, and the staging Branch should also be tested in the continuous integration environment.