“This is the ninth day of my participation in the Gwen Challenge.
preface
As you move up the front end to lead a team on a project, you’re bound to run into the headache of how the code is managed. In general, we use Git to manage code. There are several Git workflows in the industry, and each Git workflow is a code management solution. Only after you are familiar with the process of these several Git workflows can you provide a suitable code management solution to your team.
This article will detail one of these Git workflows, GitHub Flow, which I hope will help you and feel free to discuss in the comments.
I. Process concept diagram
GitHub Flow is a process concept diagram that introduces you to GitHub Flow.
Ii. Development process
In GitHub Flow, there is only one trunk branch, master. The code of this branch is considered as the code of the formal environment and cannot be directly developed on it for new features or BUG changes before committing.
The master branch can only merge other functional branches or bug-fixing branches and commit. Therefore, when developing a new feature, create a branch to develop the new feature using the master branch. The branch name can be named by the name of the feature. Here, the branch is named feature first.
As described in the process concept map:
Create a branch Creates a branch
Keep committing code to the feature branch during development.
As described in the process concept map:
Add commits Add the submission
Three, the test process
When the new feature is developed, you can initiate a pull Request, or PR for short.
As described in the process concept map:
Open a pull Request Initiates a pull request
When the project leader receives the pull request, the new feature is discussed and reviewed, and the code for the feature branch is reviewed.
As described in the process concept map:
I’d like to discuss and review that
When the project leader agrees that the new feature can be released and the code is approved. But you still need to test before pulling. Therefore, the code of the feature branch should be deployed to the test environment for testing.
Iv. BUG repair process of test environment
The bugs that appear in the test environment are directly fixed on the feature branch, and then deployed to the test environment for testing after the repair.
Release formal environmental process
In GitHub Flow, the master branch serves as the branch where the code in the formal environment resides,
When the code of the feature branch passes the test, merge the feature branch with the master branch, then deploy the code of the master branch to the formal environment, and delete the feature branch.
As described in the process concept map:
Merge and deploy Merge and deploy
The above process concept diagram is somewhat unclear about the sequence of merge and deployment, but a clearer process concept diagram is provided below.
Fix the BUG process of the official environment
As mentioned above, the code for the official environment is on the master branch, but it cannot be changed directly on the Master branch. Therefore, create a bug-fixing branch from the Master branch. The name of the branch can be either the BUG name or the fixbug plus the version number.
After the repair is completed, launch PR, deploy to the test environment for testing after PR passes, cut back to the master branch, merge the Fixbug branch, then deploy the code of the master branch to the official environment, and finally delete the Fixbug branch.