Coding Standards and Version Control

• https://www.zhihu.com/question/393040445

For merge and release, you can refer to Git Flow. However, if you do Trunk-based Development, this can also be omitted.

Author: Jacky Link: https://www.zhihu.com/question/393040445/answer/1215427425 Source: Zhihu Copyright belongs to the author. For commercial reprints please contact the author for authorization; for non-commercial reprints please indicate the source.

The main problem our team encountered in development was that when there was a lot of work on the project, the branches became a complete mess. Because we previously used Microsoft’s TFS for management, it was even messier. Later we referred to some open-source project management methods and created a GIT management method: mainly two branches, master and dev. master is always the production environment, dev is always the test environment. After testing on dev is complete, it is merged into master for release. When we need to do new features or bugfixes, we create some milestones and tasks, and branch off from dev, with the naming method “internal number/main”. Programmers then branch their own feature branches from main. After programmers finish their features, they send a pull request to a reviewer, and only then can it be merged into the main branch. When all features are done, we PR-merge main into dev and run automated tests. Then when releasing to the test environment, we put a TAG on it as the version number, for example 1.1.0, then Jenkins automatically tests and builds in the background. This can avoid the tested program not being 100% equal to the version that will be released, because too many programmers built it themselves and then delivered it, causing all kinds of problems. Manual testing; if there are no problems, schedule a date to go live; if bugs appear, run the process again and TAG a new version, for example 1.1.1. Before going live to production, merge dev into master.

• http://www.ruanyifeng.com/blog/2012/07/git.html