This article github.com/smileArchit… Has been included. JavaMap is a Java knowledge map designed to help developers learn without getting lost! Learn Java, please look at JavaMap.
As a developer you have to submit code every day, but do you really know anything about submitting code? This article gives you an overview of common code submission methods that you can use to match your team’s development patterns.
Code submission can be described in a technical term: code workflow. In the SVN era, you used a centralized workflow where everyone joined code into a master library branch. With the development of technology, the distributed code management tool represented by Git comes into being. On the basis of Git, there are many kinds of code management workflow, such as function branch workflow, Gitflow workflow and Forking workflow. Move a good small bench, the following one we explain.
Centralized workflow
Centralized workflow used SVN this way of work for students must be very familiar with, let’s think about the collaboration under the SVN experience, different development of students is to be submitted, in turn, amend the local to the server, if there is a conflict to settle the conflict of local submit again, the process of cosco side server is like a centralized management, It manages everyone’s code submission, so SVN’s development collaboration process is typically a centralized workflow.
If you switch to Git to maintain the code repository, but the developer is unfamiliar with Git’s branching mode, can you implement a similar centralized workflow with Git? The answer is absolutely yes.
Each developer clones the code from the remote repository into their own local repository, submitting the code to the local repository and then pushing it to the remote repository.
This mode is just a local repository compared to SVN, and developers with SVN experience can quickly become familiar with this mode. In previous years, many companies used Git as SVN.
From the point of view of the commit record, a centralized workflow usually follows a straight line, as shown below:
Summary: This mode is not recommended, because it completely fails to play the role of Git. It is similar to using the heavenly sword to kill the dragon to cut vegetables, which is too wasteful.
Functional branch workflow
One of the big problems with centralized workflows is that as the number of people on the team increases, each time you submit code, you may encounter conflicts, and each time you submit code, you resolve conflicts in an hour.
In order to facilitate everybody work concurrently, usually based on master the trunk pull a few feature branch, each developer focused on their own branch, need to submit code submitted directly to the characteristics of the local library branch, usually before us into the trunk pull the latest code, if there is conflict in the first local solution of conflict, After solving the problem and submitting MR application, combine the feature branch with the main trunk branch.
Under functional branch work, code is not merged directly into the main branch (master), but is usually submitted through other branches (MR), which makes it easy to integrate some automation.
After submitting your MR, your team members begin to look at your code, submit a code review, and vote on it before your Team committers accept or reject your MR.
If a large number of new functions are merged into the Master branch, the quality of the master branch may be unstable. Online suddenly have a bug to solve, for example, may only need to modify one line of code that can be solved, but the master branch is united into a large number of new features, the tester could test, that the safest way is to send code back to the last version of the time node, based on the node to modify one line of code, is not too much trouble?
To address these issues, Vincent Driessen has developed a set of Git branch management processes and specifications based on development practices, which are detailed below.
Gitflow workflow
Gitflow workflow is a very mature solution, it defines a strict branching model around project release, by allocating independent branches for code development, project release and maintenance to make the project iterative process more smooth, different from the previous centralized workflow and functional branching workflow. The Gitflow workflow has two resident branches: the master branch and the Develop branch.
The Gitflow workflow does not add any new concepts or commands compared to the functional branch workflow, which assigns specific roles to different branches and defines how and when they should interact. In addition to functional branches, separate branches are used for preparing releases, maintaining releases, and documenting releases.
Common branches of Gitflow:
-
Develop the master branch: the master branch
The code in the master branch can be deployed directly to the build environment. For stability, the code in the master branch is not modified directly, but is merged from other branches.
-
Develop the main branch: develop branch
The Develop branch is the main development branch, and contains all the code to be released to the next release, mostly merged by the Feature branch.
-
Temporary branches: feature branches
The feature branch is used to develop a new feature, and once the development is complete, the feature branch is merged into the Develop branch and removed.
-
Temporary branches: release branches
When a new release needs to be released one at a time, a release branch is created based on the Develop branch, and the master and Develop branches are merged after testers have fully tested them.
-
Temporary branch: Hotfix branch
When a new Bug is found in the build environment, if an urgent fix is needed, a hotfix branch is created, the Master and Develop branches are fully tested, and then deleted.
How do the branches work together?
1) The master/develop branch
In principle, all commits on the master branch should be tagged.
The Devlop branch is created based on the Master branch. It is the same as the master branch and will not be deleted.
Develop will evolve independently of the master and will not be tied directly to the master.
(2) Feature branch
Typically, a separate feature will be developed based on a feature branch. Feature branches do not interact with each other. Once the feature branch is developed, it is merged into the Develop branch (using merge Request or pull Request), and the life cycle of the feature branch ends.
(3) Release branch
Typically, an iteration will pull a Release branch, and developers will pull a Release branch based on the Develop branch after all of their code has been merged into the Develop branch, and testers will test against that branch.
(4) Hotfix branch
The hotfix branch is based on the Master branch. After development, you need to turn to the Master branch and the Develop branch at the same time, and tag the master branch.
Branch naming convention
The team can agree on the naming style of each branch. Here is an example for you to refer to:
- Feature branch: to
feature_Start with feature_order - Release branch: to
release_Start, such as release_v1.0 - Hotfix branch: to
hotfix_For example, hotfix_20210117 - Tag tag: if the release branch is merged, the
release_Start with, if hotfix branch mergehotfix_At the beginning.
Forking workflow
Forking workflow is a code collaboration approach represented by Github. Developers write code by Forking the source repository. Once completed, a pull request is issued and the source repository author can choose whether or not to accept the PR.
Here is a detailed explanation of the Forking workflow pattern via Github.
Find a Github open source project at github.com/smileArchit…
There are three buttons in the upper right corner: Watch, Star and Fork
Watch means to pay attention to the project. Once you click it, you will be informed of any changes in the project in the first time.
Star is similar to the meaning of “thumbs up”, give open source projects a thumbs up, encourage the author;
Fork the project to your github remote repository.
Execute the git clone command locally to clone the code to the local, submit the code after modification and push it to the personal remote repository, then launch the pull request on the interface, the original author of the project will see the PR submitted by you, and the author can choose to accept or reject the PR submitted according to the quality of the submission.
The Forking workflow is ideal for open source projects like Github, where any developer can contribute code via a fork + pull request.
conclusion
This paper introduces four types of workflow, which are centralized workflow, functional branch workflow, Gitflow workflow and Forking workflow.
Centralized workflows are common in the SVN era and are not recommended after Git.
Functional branching workflow is usually a main master branch + multiple feature branches, which is generally suitable for small team development.
The Gitflow workflow is a further evolution of the functional branch workflow, using the Master + Develop dual master branch and multiple temporary functional branches. It is a very mature way to manage code collaboratively and recommended.
The Forking workflow mainly adopts the fork + pull request mode for collaboration and is mainly used for open source projects.
Finally: these four workflow methods have their own characteristics, and the development team can choose according to their own characteristics. It is not necessary to strictly adhere to a certain way, but the one that suits them is the best. Did you get it?
— END —
Don’t waste your time, click a like, every picture is carefully drawn, the core ~
About the author: ☕ Read several books: Huazhong University of Science and Technology master degree; 😂 wave over several big factories: Huawei, netease, Baidu…… 😘 has always believed that technology can change life, is willing to maintain the original heart, refueling technical people!
Search the official account “Architect who loves laughing” on wechat, and follow this technical person who has pursuit of technology and life.
Finally, I recommend a treasure open source project, github.com/smileArchit… JavaMap is a Java knowledge map that lets developers learn without getting lost! Learn Java, please look at JavaMap. JAVA core knowledge collation (283 pages, super detailed) for free.