Shulou(Shulou.com)05/31 Report--

Today, I would like to share with you the relevant knowledge of Git workflow patterns and commands. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

The way Git works

It is divided into centralized workflow, functional branch workflow, Gitflow workflow and Forking, in which centralized workflow and functional branch workflow have been used, while Gitflow and Forking workflows have not been used yet.

Centralized workflow

A remote repository, a main branch master, where each member of the team has a local repository for code editing, temporary storage, and submission:

Git add or git add. > / `some file` represents the files to be stored temporarily, and `.` represents all the files in the working directory gie commit-m "some description" / / submission, which refers to what function or bug has been modified in this submission to facilitate future viewing of the git push-u origin master//-u option to set the local branch to track the remote corresponding branch. After setting up the tracked branch, you can use the git push command to omit the parameters of the specified push branch / / publish the local warehouse to the remote central warehouse. Origin is the remote warehouse name, master is the branch whose parameter tells Git, master represents the main branch, of course, the branch may not be the main branch.

Note: in one case, the push command will make an error, that is, if Xiao Ming publishes the code to the remote warehouse for the first time, and Xiao Hong develops his own features locally, then Xiao Hong will report an error when her own local library arrives remotely, because there is a difference between Xiao Hong's local library and the remote library, so it is necessary to pull the remote library to the local library first, and then push it to the remote library after merging with the local library.

Feature Branch Workflow

On the basis of centralized workflow, assign a special branch for each new function to be developed, that is, create a branch outside the main branch of master, push all the new functions developed by programmers to this branch, and then merge this branch into the main branch master when the function is mature.

Git checkout-b newbranch master//checkout means to create a switch with a new branch newbranch//-b means that if the new branch does not exist, a new branch is created / / the last master means that the new branch is based on the main branch

After the new branch is created, the editing, staging, and submission of it are the same as before, and the command for its push is changed to

Git push origin newbranch

When the new features are complete, use the following command:

Git checkout mastergit pullgit pull origin newbranchgit push

First, git checkout master switches to the main branch, then executes git pull to upload the main branch of the local repository to the remote repository, and then executes git pull origin newbranch to ensure that the newbranch branch and the local master branch that are already consistent with the remote are merged. You can use the simple git merge newbranch command, but the previous command ensures that it is always the latest new feature branch. Finally, re-push the updated master branch to the remote library.

Gitflow workflow

Instead of using concepts and commands that go beyond branch workflows, Gitflow workflows assign a clear role to different branches and define how and when they interact.

In addition to the main master branch, which stores the history of official releases, there is also a develop branch that acts as a branch of functional integration. After the initialization is complete, a programmer wants to develop a performance, not to pull a new branch directly from the master branch, but to use the develop branch as the parent branch, and then merge the parent branch when the new function is completed, and the submission of the new feature does not interact directly with the master branch.

Once you have enough functionality on the develop branch to make a release (or close to the established release date), checkout a release branch from the develop branch. The new branch is used to start the release cycle, so no new functionality can be added to this branch from this point in time-- this branch should only do Bug fixes, document generation, and other release-oriented tasks. Once the external release work is complete, the release branch is merged into the master branch and assigned a version number to type the Tag. In addition, these changes made since the new release branch are merged back to the develop branch.

Maintenance branch

The maintenance branch, or hotfix branch, is used to generate quick patches to the product release (production releases), which is the only branch that can be fork directly from the master branch. When the repair is complete, the changes should be merged back to the master branch and the develop branch (the current release branch), and the master branch should type Tag with the new version number.

Use a dedicated branch for Bug fixes so that the team can deal with the problem without interrupting other work or waiting for the next release cycle. You can think of the maintenance branch as a temporary release that is processed directly on the master branch.

Work flow

Equip a master branch with a develop branch

Git branch developgit push-u origin develop

Later this branch will contain the full history of the project, while the master branch will contain only part of the history. Other developers should then clone the central repository and set up the tracking branch of the develop branch:

Git clone ssh://user@host/path/to/repo.gitgit checkout-b develop origin/develop

Every developer now has local copies of these historical branches.

Xiao Hong and Xiao Ming start their own functional development as team members. They need to create branches for their respective functions. The new branch is not based on the master branch, but should be based on the develop branch:

Git checkout-b some-feature develop

They use the old routine to add and submit to their respective functional branches: edit, temporarily, submit:

Git statusgit add git commit

After the submission has been added and the function OK has been added, if the team uses Pull Requests, you can initiate one for merging into the develop branch. Otherwise, she can merge directly into her local develop branch and push to the central warehouse:

Git pull origin developgit checkout developgit merge some-featuregit pushgit branch-d some-feature

The first command ensures that the develop branch is up-to-date before merging functions. Note that functionality should never be merged directly into the master branch. Conflict resolution is the same as a centralized workflow.

Forking workflow

Distributed workflow, which makes full use of the advantages of Git in branching and cloning, can manage large teams of developers (developer) and accept submissions from untrusted contributors (contributor). This workflow allows every developer to have a server-side repository (this repository can only be push, but everyone can pull modify it), each programmer can push code to his own server repository, but can not push to the formal repository, only the project maintainer can push to the formal repository, so that the project maintainer can accept any developer's submission, but does not need to give him the write permission of the formal code base.

This kind of workflow is suitable for open source projects in the online open source community, where everyone contributes to the project, but a person or team manages the project as a developer, and the code of all contributors is reviewed by the developer, and then push to the official warehouse by the developer after its function is improved.

Pull Request

Pull Request is a special forum for discussing submission features and a friendly web interface (there is also an option in personal github projects), in which you do some Code Review work, feed the results back to Pull Request, and you can also push the new submission fine-tuning function. When the discussion is over, the eye-catching maintainer merges all the functions into the official warehouse and closes Pull Request.

To initiate a Pull Request is to request another developer to pull a branch of your own repository to its repository, so you need to provide four pieces of information: source repository, source branch, destination warehouse, and destination branch.

Pull Request can be used for the other three workflows in addition to centralized workflows, because they require either different branches or different warehouses, while centralized workflows have only one warehouse and one master branch.

Example:

Using Pull Request in a functional branch workflow

The functional branch workflow has only one open repository, so the destination repository and the source repository of the Pull Request are always the same. Usually the developer will specify his functional branch as the source branch and the master branch as the destination branch.

Upon receipt of the Pull Request, the project maintainer decides what to do. If the functionality is fine, simply merge into the master branch and turn off Pull Request. But if there is a problem with the submitted change, he can give feedback in Pull Request. After that, the newly added submission will also be commented and then displayed.

It is also possible to launch a Pull Request before the feature is fully developed. For example, if a developer has trouble implementing a requirement, he can send a Pull Request that includes work in progress. Other developers can provide advice on Pull Request, or even add submissions directly to solve the problem.

These are all the contents of the article "how to use Git Workflow patterns and commands". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

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.