Shulou(Shulou.com)06/01 Report--

This article will explain in detail the knowledge about how to analyze git. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Branch management strategy

Git branch is powerful and flexible at the same time. Without a good branch management strategy, the team will merge and push at will, which will cause branch confusion, various coverage, conflict, loss and other problems.

At present, the most popular branch management strategy, also known as Workflow, consists of three main types:

Git Flow

GitHub Flow

GitLab Flow

According to the actual situation, our front-end team has worked out its own set of branch management strategy.

We divide the branches into four broad categories:

Dev-*

Develop

Staging

Release

Dev-* is a general term for a group of development branches, including personal branches, module branches, repair branches, etc., on which team developers develop.

Before development, the latest code of the develop branch is merged through merge; after development, it must be merged back to the develop branch through cherry-pick.

Develop is a separate branch that retains the latest and complete development code corresponding to the development environment. It only accepts cherry-pick merges and does not allow merge.

The staging branch corresponds to the test environment. When the develop branch has updates and is ready to release tests, staging merges the develop branch through rebase and then publishes the latest code to the test server for testers to test.

After the test finds a problem, follow the process of dev-*-> develop-> staging until the test passes.

Release represents the production environment. The latest submission of the release branch is always in sync with the online production environment code, that is, the release branch is ready to release.

When the staging test passes, the release branch merges the staging branch through rebase, and then releases the latest code to the production server.

Summarize the merger rules:

Develop-> (merge)-> dev-*

Dev-*-> (cherry-pick)-> develop

Develop-> (rebase)-> staging

Staging-> (rebase)-> release

Why do I have to use cherry-pick to merge into develop?

Using merge merging, if there is a conflict, there will be bifurcations; there are many and miscellaneous branches of dev-*, and direct merge to develop will produce intricate bifurcations, so it is difficult to sort out the progress of submission.

On the other hand, cherry-pick only merges the required commit into the develop branch, and does not produce bifurcations, so that the git submission graph (git graph) is always in a straight line.

In addition, after the module development branch is completed, you need to merge multiple commit into a single commit, and then merge into the develop branch to avoid redundant commit, which is one of the reasons for not using merge.

Why do I have to use rebase to merge into staging/release?

Rebase is translated as a variable base, and merging also does not produce bifurcations. When develop updates a lot of features, to merge into staging testing, it is impossible to merge commit with cherry-pick one by one. Therefore, it is necessary to merge the past at one time through rebase, and ensure that staging and develop are fully synchronized.

The same is true of release. After passing the test, staging is merged with rebase at one time, which also ensures that staging and release are completely synchronized.

Commit specification and submission verification

Commit specification refers to the description information filled in during git commit, which should be in accordance with the unified specification.

Just imagine, if the commit of team members is randomly filled in, it is difficult to control the progress when others have no idea what the commit has accomplished or what Bug has been fixed during collaborative development and review code.

In order to visually see the updates to commit, the developer community has created a specification that divides commit by function and adds some fixed prefixes, such as fix:,feat:, to mark what the commit mainly does.

At present, the mainstream prefixes include the following:

Build: represents a build, which is available in the release version

Ci: update automatic configuration such as CI/CD

Chore: miscellaneous, other changes

Docs: updating documents

Feat: commonly used, indicating new features

Fix: commonly used: repair bug

Perf: performance optimization

Refactor: ReFactor

Revert: code rollback

Style: style Chan

Test: unit test changes

These prefixes are written every time they are submitted, and many people can't remember them at first. A very useful tool is recommended here that can generate prefixes automatically. Here's the address.

First, install globally:

Npm install-g commitizen cz-conventional-changelog

Create a ~ / .czrc file and write the following:

{"path": "cz-conventional-changelog"}

You can now replace the git commit command with the git cz command, with the following effect:

Then select the prefix from up and down the arrow, and you can easily create a submission that conforms to the specification according to the prompt.

With the specification, it is not possible to rely on people's conscious compliance, and it is necessary to verify the submitted information in the process.

At this point, we are going to use a new thing-- git hook, that is, the git hook.

The role of git hook is to trigger a custom script before and after the git action occurs. These actions include submit, merge, push, etc., and we can use these hooks to implement our business logic in all aspects of the git process.

Git hook is divided into client hook and server hook.

There are four main client hook:

Pre-commit: run before submitting information to check the code of the staging area

Prepare-commit-msg: not frequently used

Commit-msg: very important. Use this hook to check the submission information.

Post-commit: run after submission is completed

The server hook includes:

Pre-receive: very important. All kinds of checks before push are here.

Post-receive: not frequently used

Update: not frequently used

Most teams do validation on the client side, so we use commit-msg hooks to validate commit information on the client side.

Fortunately, there is no need for us to write check logic manually, the community has a mature solution: husky + commitlint

Husky is the artifact that creates git client hooks, and commitlint verifies that commit information conforms to the above specifications. Together, the two can prevent the creation of submissions that do not conform to the commit specification and guarantee the submission of the specification from the source.

For more information on how to use husky + commitlint, please see here.

Withdrawal scheme of misoperation

The frequent use of git to pull and push code in development will inevitably lead to misoperation. Don't panic at this time. Git supports withdrawal in most scenarios. Let's summarize it.

There are two main commands to withdraw: reset and revert

Git reset

The principle of the reset command is to restore the version based on commitId. Because a commitId is generated for each submission, reset can help you restore any version of history.

The version here has the same meaning as submission, and a commitId is a version.

The reset command format is as follows:

$git reset [option] [commitId]

For example, to withdraw to a submission, the command is as follows:

$git reset-hard cc7b5be

How did commitId get the above command? Very simple, use the git log command to view the submission record, you can see the commitId value, this value is very long, we can take the first seven digits.

The option here uses-- hard, which actually has three values. The specific meaning is as follows:

-- hard: undo commit, undo add, delete workspace change code

-- mixed: default parameter. Undo commit, undo add, restore workspace change code

-- soft: undo commit, do not undo add, and restore the workspace change code

Pay special attention here-- hard, using this parameter to restore will delete the workspace code. In other words, if you have uncommitted code in your project, using this parameter will delete it directly. It can't be recovered. Be careful!

In addition to using commitId recovery, git reset provides a shortcut to revert to the last commit:

$git reset-soft head ^

Head ^ represents the previous submission and can be used multiple times.

In fact, the most common misoperation in daily development is as follows: just after the submission, a problem is suddenly found, such as the submission information is not well written, or there are omissions in code changes, and then you need to withdraw to the last submission, modify the code, and then resubmit.

The process goes something like this:

# 1. Roll back to the last submitted $git reset head ^ # 2. Modify code. # 3. Add temporary deposit $git add. # 4. Resubmit $git commit-m'fix: * git also provides a more convenient method for this process: $git commit-amend

This command directly modifies the current submission information. If the code changes, execute git add first, and then execute this command, which is faster and more convenient than the above process.

Another very important feature of reset is the true fallback of a version.

What do you mean? For example, the current submission, you have pushed to the remote warehouse; now you have withdrawn a submission with reset, and the local git repository lags behind the remote warehouse by one version. If you push at this time, the remote warehouse will refuse and ask you to pull first.

If you need a fallback version of the remote repository, you need the-f parameter to force the push, and the local code will overwrite the remote code.

Note that the-f parameter is very dangerous! If you are not familiar with the principle of git and the command line, remember not to use this parameter.

If you withdraw the previous version of the code, how can it be more secure to synchronize to the remote?

The plan is the second command to be said below: git revert

Git revert

Revert is the same as reset, both of which are recovery versions, but they are implemented differently.

To put it simply, reset reverts directly to the previous commit, and the workspace code is naturally the code of the last commit; while revert is a new commit, but this commit is the code that uses the last commit.

Therefore, the two restored codes are the same, with the difference being a new commit (revert) and a fallback commit (reset).

Just because revert is always adding submissions, the local warehouse version can never lag behind the remote warehouse and can be pushed directly to the remote warehouse. Therefore, the problem of adding-f parameter to push after reset is solved, and the security is improved.

After talking about the principle, let's take a look at how to use it:

$git revert-n [commitId]

Mastering the principle is very easy to use, as long as a commitId is fine.

Tag and production Environment

Git supports a tag tag for a historical submission, which is often used to identify important version updates.

At present, it is common practice to use tag to represent the version of the production environment. When the latest submission passes the test and is ready for release, we can create a tag that represents the production version to be released.

For example, I want to send a version of v1.2.4:

$git tag-a v1.2.4-m "my version 1.2.4"

Then you can view:

$git show v1.2.4 > tag v1.2.4Tagger: ruims Date: Sun Sep 26 10:24:30 2021 + 0800my version 1.2.4

Finally, use git push to push tag to the remote:

$git push origin v1.2.4

Note here: tag has nothing to do with which branch is created, tag is just an alias for submission. Therefore, the ability of commit tag can be used, such as the git reset,git revert command mentioned above.

When there is a problem with the production environment and you need a version fallback, you can do this:

$git revert [pre-tag] # if the previous version is v1.2.3, then: $git revert v1.2.3

In warehouses with frequent updates and a large number of commit, the version marked with tag is obviously cleaner and more readable.

Think about the usefulness of tag from another perspective.

As mentioned in the branch management policy section above, the release branch is synchronized with the production environment code. In the process of continuous deployment of CI/CD (described below), we are listening for the push of the release branch and then triggering the automatic build.

Is it also possible to monitor tag pushes and trigger automatic builds, so that version updates are more intuitive?

Many uses still need to be considered.

Put an end to 443 Timeout permanently

The code repository within our team is GitHub, and for well-known reasons, GitHub pull and push are very slow, even reporting errors directly: 443 Timeout.

Our starting plan is to turn on VPN by all staff. Although the speed is good most of the time, there is an occasional hour or even a day when the code can not be pushed up, seriously affecting the progress of development.

Then it occurred to me that the slow timeout was due to the fact that the home page of GitHub could not be opened. To investigate the root cause, what is blocked is the http or https protocol when visiting the website, so will there be no wall in other protocols?

Do it when you think about it. We found that GitHub supports the ssh protocol in addition to the default https protocol. So I'm going to try cloning the code using the ssh protocol.

One of the more troublesome things about using ssh is to configure secret-free login, otherwise you have to enter your account password every time you pull/push.

In short, after generating the public key, open the GitHub home page, click Account-> Settings-> SSH and GPG keys-> Add SSH key, and then paste the public key into it.

Now, let's clone the code using the ssh protocol, as an example:

$git clone git@github.com: [organi-name] / [project-name]

Found that it was cloned in an instant! Test the pull/push a few more times and fly at speed!

No matter which code management platform you use, if you encounter 443 Timeout problems, please try the ssh protocol!

Hook implementation deployment?

Deployment using git hook should be an advanced application of hook.

There are many tools, such as GitHub,GitLab, that provide continuous integration, that is, listening for a branch push, then triggering an automatic build and automatic deployment.

In fact, no matter how fancy these tools are, the core functions (listening and building) are provided by git. Only in the core functions to do a better integration with their own platform.

Let's put aside these tools today, go back to the source, and use pure git to automate the deployment of a react project. With this core logic mastered, the continuous deployment of any other platform is less mysterious.

Ultimate application: CI/CD

Some of the above also mentioned continuous integration, continuous deployment of these words, now, she came out shyly, the protagonist officially appeared on the stage!

It can be said that all the specifications and rules written above are for the better design and implementation of the protagonist-CI/CD.

First of all, what is CI/CD?

The core concept, CI (Continuous Integration), is translated as continuous integration. CD consists of two parts, continuous delivery (Continuous Delivery) and continuous deployment (Continuous Deployment).

From a global perspective, CI/CD is a way to frequently deliver applications to customers through automated processes. This process runs through the entire life cycle of application integration, testing, delivery and deployment, collectively referred to as the "CI/CD pipeline".

Although both are pipelines as automated as pipelining, CI and CD have their own division of labor.

Continuous integration is the frequent integration of code into the trunk branch. When the new code is submitted, the build and test will be executed automatically, and the test pass will be automatically merged into the trunk branch, which enables the product to iterate quickly while maintaining high quality.

Continuous delivery is the frequent delivery of new versions of software to quality teams or users for review. If the review is passed, the production environment can be released. Continuous delivery of required code (the latest submission of a branch) is a state that can be released at any time.

Continuous deployment is when the code is automatically deployed to the production environment after it has been reviewed. Continuous deployment requires that the code (the latest commit of a branch) is ready to deploy.

The only difference between continuous deployment and continuous delivery is whether deployment to a production environment is automated.

Deployment automation may seem like a small step, but in practice, you will find that it is the most difficult part of the CI/CD pipeline.

Why? First of all, from continuous integration to continuous delivery, these steps are implemented by the development team. Through collaboration within the team, we have produced a new version of the application to be released.

However, it is the job of the operations team to deploy the application to the server. If we want to achieve the deployment, we have to communicate with the operation and maintenance team, but the developer students do not understand the server, and the operation and maintenance students do not understand the code, so it is difficult to communicate.

In addition, the operation and maintenance is manual deployment, we want to achieve automatic deployment, we must have server permissions to interact with the server. This is also a big problem, because the operation and maintenance team is bound to worry about security issues, so the promotion is constantly blocked.

At present, there are many mature CI/CD solutions in the community, such as circleci used by the old jenkins,react, and GitHub Action, which I think is the best to use. We can integrate these programs into our own system.

This is the end of the knowledge about how to analyze git. I hope the above content can help you to some extent and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.