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

This article mainly explains "the method of building Git warehouse and branch management". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the method of building Git warehouse and branch management".

1. What is Git?

Git is an open source distributed version control system that can effectively and quickly handle project version management from very small to very large. Git is developed and implemented in C language.

2. Comparison between Git and SVN

Git and SVN are two completely different version control systems, Git is a distributed version control system, and SVN is a centralized version control system. To compare the difference between Git and SVN, you first need to understand the basic concepts of distributed version control systems and centralized version control systems.

Centralized version control system: a remarkable feature is that the version library is stored on the central server, which uniformly manages the version information and branch information of the project. Each member of the team needs to pull the latest code from the central server before getting to work. After the work is done, the code is submitted to the central server. The centralized version of the server has two disadvantages:

You have to be connected to work, and when there is no network or the network is poor, the members of the team cannot work together.

The security is not good because the version inventory is placed on the central server, and when the central server is damaged, the version library will be lost, making it impossible for all members to work.

It can be seen that the working computers of all members of the team only deal with the central server. If the version library is compared to a library, then everyone (every computer) needs to borrow a book from the library (pull the latest code), read it, and then return it to the library (modify and submit it to the central server).

Distributed version control system: the biggest difference from a centralized version control system is that all members of the team have a complete version library on their working computers and there is no central server. This is equivalent to that each member of the team has its own small library (version library), and members can exchange books in their own library (submit their own changes to each other). There is no need for a central server to manage coordination management at all.

When actually using a distributed version control system, it is rare to push a version library on a computer between two people, because sometimes you are not on the same LAN, or your colleague's computer is turned off. Therefore, the distributed version control system usually has a computer that acts as a "central server", but the function of this server is only to facilitate the "exchange" of everyone's changes, and everyone will do the same without it. It's just that it's not convenient to exchange changes. The version library on this computer that acts as the "central server" is called the remote version library, and the version library on the other member computers is called the local version library.

The distributed version control system removes the central server, which fully embodies the core concept of distribution, that is, decentralization. There are two benefits to this:

Work without a network: every member of the team can work without a network, because there is a complete local version library and there is no need to worry about data loss.

Data is more secure: when one member's computer breaks down, it doesn't matter, just make a copy from another member's computer. However, if there is a problem with the central server of the centralized version control system, the version library may be lost, making it impossible for everyone to work.

3. System environment system version WindowsWindows10LinuxUbuntu16.044. Install the Git client

After talking about the basic concepts of Git, let's install a Git client to play. Here is a brief introduction to the installation of the Git client under different operating systems.

Under the Linux system

First, use the git-- version command to see if the Git client is installed on the computer.

If it is already installed, you can skip this section. If it is not installed, move on to the following:

There are different distributions of Linux systems, and you can view the version of Linux through the cat / proc/version command.

Install Git under Debian or Ubuntu

You can install Git from Debian or Ubuntu through the apt package management tool, with the following command:

Sudo apt-get install git

Install Git under Red Hat or CentOS

You can install Git through the yum package management tool under Red Hat or CentOS, with the following command:

Yum install git-y

If you cannot find the yum command, you need to install the yum tool first. You can refer to the following command

# Delete all files rm-f / etc/yum.repos.d/*# in the yum.repos.d directory and then download Ali's yum source wget-O / etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo# to clean the cache under the yun clean allWindows system

After downloading the installation package, click next to install it. I won't repeat it again.

5. Local version library operation

After installing Git under Windows, two applications, Git Bash and Git GUI, appear, in which Git Bash is the command line tool for Git and Git GUI is the visualization tool for Git (rarely used).

Create a local version library

There are two steps to creating a local version library:

The first step is to create an empty folder named: git_learn.

The second step is to execute the git init command under the folder to turn the folder into a version library that git can manage.

After performing the second step, a hidden folder named .git appears in the git_learn directory, which is the version library of git. Remember not to manually modify anything under the .git folder in case the local version library becomes unavailable.

Once the local version library is built, you can create a file under the git_learn folder for testing. Here you create a file called readme.txt.

Add to staging area

The readme.txt file can be submitted to the staging area through the git add readme.txt command (the concept of the staging area will be described in more detail later). If you have more than one file to add, you can execute git add. Orders.

Submit to the version library

Because git has a full version library locally, you also need to submit the previously created readme.txt file to the current branch of the local version library, which is master by default. The command format is git commit-m', in which your submission comments are written.

Work area and staging area

There are two very important concepts here, one is the workspace, and the other is the staging area (a concept unique to Git).

Work area

A workspace is a directory that you can see on your computer (excluding hidden files). For example, the git_learn directory is a workspace.

Temporary storage area

The workspace has a hidden directory. Git, which is not a workspace, but a version library of Git, the most important of which is the stage.

There is also the first branch that Git automatically creates for us called master, and a pointer to master called HEAD.

The ABC folder in the workspace is submitted to the staging area stage through the add command, and the ABC folder in stage is submitted to the current branch master through the commit command.

Manage modification

Git manages changes, not files. The modification here refers to any operation on the workspace, including adding files, deleting files, modifying files, and so on. Even adding a sentence to the file or deleting a character can be regarded as a modification. As an example, take the readme.txt file as an example:

Add a word gittest to the readme.txt file for the first time. Then execute git add readme.txt and check the status with the command git status.

Hello world

Gittest

The second time, add a line of content git tracks changes to the readme.txt file.

Hello world

Gittest

Git tracks changes

Execute the git commit-m 'git tracks changes' command directly. Then through git status, you can find that the second change was not committed. This is because the second change is not first committed to the staging area.

Our operation procedure is the first modification-> git add-> the second modification-> git commit. When using the git add command, the first change in the workspace is placed in the staging area, ready to commit, and the second modification in the workspace is not placed in the staging area, so git commit is only responsible for committing the changes in the staging area to the current branch. So the second revision was not submitted.

That is, all changes must be submitted to the staging area through git add and then to the current branch via git commit. In actual development, it is common to merge all the changes into add, and then commit together.

Delete a file

There is an obsolete file on the current branch. How should I delete it? For example, to delete a file called test1.txt. It only takes two lines of command.

Git rm test1.txtgit commit-m "remove test.txt" 5.Ubuntu builds a private git warehouse

The previous introduction in the actual development, generally take a computer as a "central warehouse", the computer that acts as a central warehouse needs to install a code warehouse software, here the choice of open source software GitLab, which is based on git implementation of online code warehouse software, provides web visual management interface, can be deployed locally. It is usually used for collaborative development within enterprise teams. Of course, if you don't want to build a private git warehouse, you can also use Github, the largest same-sex dating site (using something similar to GitLab).

So how to install GitLab software on Ubuntu and build a private Git repository?

Install some of the necessary services

# update the apt source sudo apt-get update# installation dependency package, and run the command sudo apt-get install curl openssh-server ca-certificates postfixsudo apt-get install-y postfix

Then trust GitLab's GPG public key:

Curl https://packages.gitlab.com/gpg.key 2 > / dev/null | sudo apt-key add-& > / dev/null

Configure the mirror path

Because the download speed of foreign countries is too slow, so configure the path of Tsinghua University image.

Sudo vi / etc/apt/sources.list.d/gitlab-ce.list

Write the following code in the file

Deb https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu xenial main

Install gitlab-ce

Sudo apt-get updatesudo apt-get install gitlab-ce

After the installation of gitlab-ce is successful.

5. Modify external url

Modify the external url in the gitlab configuration file / etc/gitlab/gitlab.rb to your own ip address or domain name.

Sudo vi / etc/gitlab/gitlab.rb

Find external_url and change its default address to my local local area network IP:192.168.40.138.

The local area network ip address of external_url 'http://192.168.40.138/' # # is 192.168.41.128

Perform configuration

If the previous steps go well, you can perform the configuration, which may take a long time.

Sudo gitlab-ctl reconfigure

Start GitLab

Sudo gitlab-ctl start

You can check whether GitLab starts successfully with the ps-ef | grep gitlab command.

8. Make browser access

After GitLab starts successfully, you can access GitLab's home page through a browser. Enter http://192.168.40.138/; on the browser

The user name entered by default is the root user, and the password entered is the account password of root.

At this point, the installation of GitLab is all over, and we have successfully built our own Git repository.

Use of GitLab to add users

Click the settings button to enter the settings bar, and select Users- > New User to enter the add user page.

Enter a name, user name, and mailbox to register and add a new user.

Add a team

After the user is added, the user is added to the team. By default, there will be a team named GitLab Instance in GitLab, and you can also add your own team. Here I add a team named ai_edu. And added two members to the team.

Select the team to which you want to add members, and a column adding Add user (s) to the group appears on the right. Then all users in this column and add to the team. The roles of users include tourists, testers, developers, managers, owners, and so on.

Build a new remote warehouse

After talking about the user and team settings, now it's time to focus on how to build a new remote warehouse. It is also more convenient. The procedure is: Project- > Your projects- > New project

A new remote warehouse called git_test is built here, and all of it belongs to the ai_edu team.

There are three permission levels in the repository: Private (only people on your team can pull and push code) and Internal (users other than blacklisted users can pull and push code). Public (all users can pull it).

Configuration of SSH key (generating public and private keys)

Why configure SSH key? This is because GitLab communicates with your computer through the SSH protocol. To put it bluntly, if you don't configure SSH key, you can't push the code to the remote library. Here, first generate the public key and private key files locally, and then copy the contents of the public key files to the GitLab.

Configure user name

Git config-global user.name "username"

Configure mailbox

Git config-global user.email jayxiang31@gmail.com

Replace jayxiang31@gmail.com with your actual email address. There is no need for single quotation marks.

4. Generate public and private keys

Ssh-keygen-C'you email jayxiang31@gmail.com'-t rsa

If it is simple, you can fill in the ssh-keygen command directly. Email address fill in the email address set above. Press Enter all the time if prompted.

2 find the public key file id_rsa.pub and copy the contents of the public key to GitLab

6. Branch management creates and merges branches

The concept of branch: a branch is a timeline connected by the points created by each submission. This timeline is a branch, and by default there is only one main branch, master branch. Strictly speaking, HEAD does not point to the commit, but to the master,master points to the commit, and HEAD points to the current branch.

At the beginning, the master branch is a line, and Git points to the latest commit with master, and then to master with HEAD, you can determine the current branch and the submission point of the current branch.

Each time you commit, the master branch moves forward so that as you continue to submit, the line of the master branch will get longer and longer.

1. Create a dev branch

When we create a new branch dev, Git creates a pointer dev to the current commit point of the master branch. When you switch to the dev branch, the HEAD pointer points to dev. That is, the HEAD always points to the current branch.

Git checkout-b dev

Git checkout plus the-b parameter means to create and switch to the dev branch, which is equivalent to the following two commands.

$git branch dev$ git checkout dev

When the code is submitted on the dev branch (the master branch is not changed), the dev branch continues to push backwards. The point of the master pointer does not change.

The git checkout command is a special command, and passing in different parameters will have a very different effect. For example, the git checkout-- file command means to undo all changes in the file file. So Git also provides git switch commands for creating and switching branches.

# # create and switch to a new dev branch git switch-c dev## and switch to the existing master branch git switch master2. View all branches

After the branch is created, you can view it with the git branch command.

3. Branch merging

When team members have finished developing on the dev branch, they can merge the content from the dev branch into the master branch, which works by pointing the master pointer to the current submission of the dev. Git merge branch only changed the pointer, the content of the workspace has not changed.

The command to merge is divided into two steps. The first step is to switch to the master branch, and the second step is to merge the dev branch.

# switch to master branch git checkout master# and merge dev branch git merge dev

Delete dev Branch

Now that the contents of the dev branch are merged into the master branch, you can delete the dev branch. Git deleting the dev branch is actually deleting the dev pointer. After deletion, only the master branch is left. It is important to note that you must switch to the master branch before deleting the dev branch. The command to delete the dev branch is as follows:

Git branch-d dev to resolve conflicts

In the process of teamwork, it is inevitable to encounter all kinds of modification conflicts. So how to resolve these conflicts? For example, if you and your colleague modify the readme.txt file separately, there will be a conflict when you submit it at the same time. Or you modify the readme.txt file on the master branch and the feature1 branch respectively. Then there will be conflicts when you merge the feature1 branch into the master branch. Give me a chestnut:

Text processing conflicts are added to the readme.txt file on the feature1 branch. Then submit it to the feature1 branch.

Switch to the master branch and add text to the readme.txt file

Conflict handling master has conflicts

Then submit it to the master branch.

3. Merge the feature1 branch into the master branch, and a merge conflict occurs. As shown in the following figure:

After the conflict, Git marks the contents of different branches with. As shown in the following figure:

The way to deal with conflicts is to edit the content of conflicts. And resubmit it.

Comparison of $git add README.md$ git commit-m "conflict resolution"

Compare the differences between two submissions, git diff 36e4fd7 b55da38

Comparing the differences between the work area and the warehouse area, HEAD said the latest submission of git diff HEAD

Branch management strategy

Typically, Git uses Fast forward mode when merging branches. However, in this mode, the branch information is lost after the branch is deleted. As shown in the following figure, after the dev branch is deleted, the branch information is lost.

If you want to forcibly disable Fast forward mode, Git generates a new commit when merge. When you delete a branch, the branch information is not lost. The order is

Git merge-no-ff-m "merge with no-ff" dev

Prepare to merge dev branches, where the-- no-ff parameter indicates that Fast forward is disabled, because this merge creates a new commit, so add the-m parameter. Write the commit description in.

Bug branch

When you receive a task to repair the bug code 01, naturally, you will create a branch issue-01 to repair it, but if this is the work you are doing on the dev branch has not been submitted, submit it, but your work on dev is only general, can not be submitted, it is estimated that it will take 1 day to complete. However, you must now fix the bug code 01 within two hours. What should I do at this time? Don't you expect a feature to hide your current uncommitted work on dev, and then switch to the issue-01 branch to modify the bug?

Through the stash function, you can meet your wishes and hide the current work site. As shown in the following figure: after executing the git stash command, the newly created hello.html file disappears from the workspace.

Save the work site git stash

The git stash command hides currently uncommitted work. Make your work area clean and refreshing.

View the work site

Git stash list can view all saved work sites in the current warehouse.

Git stash list resumes work site

Now that the bug code 01 has been fixed, you can switch to the dev branch for development. So the first thing you need to do at this time is to restore the previously saved work site. The order to restore the work site is:

Git stash apply deletes the work site

The work site can be restored through the git stash apply command. However, the work site is still there after recovery. So at this time, we also need an order to delete the work site. The orders are:

Git stash drop restores and deletes the work site

A command to restore the work site, and another order to delete the work site. It's a little cumbersome. Is there an order to combine the two into one? The answer is yes: it can be done with the following command:

Git stash pop

After fixing the bug on the master branch, we think that the dev branch was separated from the master branch early, so this bug actually exists on the current dev branch. So how do you fix the same bug on the dev branch? Repeat the operation once and submit it. This method is not bad, if the BUG involves too many changes, this approach seems a bit stretched. So can we copy the submission made by the modified BUG to the current dev branch? The answer is yes:

Merge a certain submission git cherry-pick 821ea4d

A single commit can be copied to the current branch through the git cherry-pick command. The version number of the submitted submission can be viewed through git log.

Feature branch

When adding a new feature, you certainly do not want to mess up the main branch because of some experimental code, so every time you add a new feature, it is best to create a new feature branch, develop above, complete, merge, and finally, delete the feature branch.

As described earlier, branches can be deleted through the git branch-d branchname command. However, if the deleted branch has not been merged into the main branch, using this command to delete the branch, Git will throw an error and cannot delete the branch. As follows: to delete a branch named feature-01. But the branch has not been merge. At this point, you need to force the command to delete the branch.

Git branch-D feature-01

Feature-01 is the name of the branch to be deleted. In fact, it is to replace the-d parameter with the-D parameter.

Remote warehouse (multi-person collaboration)

As I have said so much, it seems that one person is operating locally and does not involve the cooperation of many people. This is certainly impossible in team development, because we are a team. So what are the actions involved in the collaboration of so many people?

Local warehouse association remote warehouse git remote add origin http://192.168.40.138/ai-edu/git-demo.git

Alternatively, the following is recommended because the SSH public and private keys were previously configured

For the first time, git remote add origin git@gitee.com:jayxiang31/python_learn.git pulls files such as README.md and .gitignore from the remote library git pull-- rebase origin master clone remote repository

The private Git warehouse manager GitLab has been built in the previous third chapter. A warehouse called git_test has also been created. What needs to be done now is to clone the remote warehouse. The command to clone is git clone

Git clone http://192.168.40.138/ai-edu/git_test.git

Where http://192.168.40.138/ai-edu/git_test.git is the address of the remote warehouse.

Of course, it can also be operated directly through the graphical interface on IDEA, eliminating the process of importing the project. The operation steps are as follows:

Select File- > New- > Project from Version Control- > Git.

Fill in the address of the remote warehouse in URL and click the Clone button.

It is important to note that only master branches are cloned by default, and other branches are not cloned. Other branches need to be pulled through the git pull command, which will be described in more detail later.

Delete remote Git warehouse git remote rm origin to view remote branches

The remote repository can be viewed through the git remote command, where origin represents the remote host.

The git remote-v command allows you to view the details of the remote warehouse, including the address of the remote warehouse.

$git remote-vorigin http://192.168.40.138/ai-edu/git_test.git (fetch) origin http://192.168.40.138/ai-edu/git_test.git (push)

It shows the address of the origin that can be crawled and pushed. If you don't have push permission, you won't see the address of push.

Push branch

Now that the remote repository has been cloned, how do you push all local commits on the current branch to the remote repository? The answer is through the git push command, whose syntax structure is git push, which represents the remote branch name and the local branch name.

Git push origin master

This statement means that the local master branch is pushed to the remote origin branch. In practical applications, the-u parameter is added to the git push command, just like git push-u origin master. This is because if the current branch has a tracking relationship with multiple hosts, you can specify a default host with the-u parameter so that you can use git push later without any parameters. So which branches should be consistent with remote branches? It is generally believed that:

The master branch is the main branch and needs to be synchronized with the remote at all times.

The dev branch is the development branch, and all members of the team need to work on it, so it also needs to be synchronized remotely.

The bug branch is only used to repair bug locally, so there is no need to push it remotely, unless the boss wants to see how many bug you fix each week.

Whether the feature branch is pushed remotely depends on whether you work with your partner to develop on it.

To put it bluntly, the branches that need teamwork must be pushed to the remote library, otherwise they will not be needed.

Create a remote branch

Remote branches can also be created through the git push command.

Git push origin dev

Suppose you already have a dev branch locally. With the above command, you can push the dev branch to the remote library and create a remote dev branch.

Pull branch

The data and branch information of the remote warehouse can be pulled through the git pull command. Suppose this scenario: your colleague creates a dev branch locally and submits it to the remote library. At the same time, you have also created a dev library locally, which will fail when you push. The result is shown in the following figure:

Because the latest submission from your colleague conflicts with the submission you are trying to push. The solution is to use git pull to grab the latest submission from origin/dev, as prompted by Git, and then merge locally to resolve the conflict before pushing.

$git pullThere is no tracking information for the current branch.Please specify which branch you want to merge with.See git-pull (1) for details. Git pull If you wish to set tracking information for this branch you can do so with: git branch-- set-upstream-to=origin/ dev

Git pull also failed. The reason is that the link between the local dev branch and the remote origin/dev branch is not specified. According to the prompts, set the link between dev and origin/dev:

Associate local branch with remote branch $git branch-- set-upstream-to=origin/dev devBranch 'dev' set up to track remote branch' dev' from 'origin'.

After associating the local branch with the remote branch, it will be successful in pull. Git pull is successful this time, but there is a conflict in the merger, which needs to be resolved manually. The solution is also to manually handle the conflict file locally, and after resolution, submit it in push.

Delete remote branch

Pass through

Git push origin: dev

Command to delete a remote dev branch. But at this time, the local dev branch still exists. So you also need to delete the local dev branch through git branch-d dev.

View Branch

You can view local branches through git branch

Git branch-an allows you to view both local and remote branches.

Version fallback

In actual development, we often encounter such a scenario, such as: what should you do when you mistakenly submit a piece of problematic code, causing other colleagues to update the code and the project can't start? The first thing that comes to mind is to roll back the version. Fall back to the previous version that has no problem.

Use the git log command to find all the submission logs for the current warehouse. Then, find the version you need to fall back to. As shown in the following figure:

Fallback to the previous version: git reset HEAD

Fallback to the specified version: git reset commitId, where commitId is the version number of the specified version, for example, fallback the version information to the b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602 version. Then the order is:

Git reset b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602

After fallback, check through git log again, and the latest commit log has become the hello commit version.

Of course, it's easier to roll back and forth via IDEA. Right-click Version Control- > Log on the version to be rolled back to, and select Reset Current Branch to Here.

In fact, the essence of the fallback operation is to point the HEAD pointer to the version to be rolled back.

Branch renamed git branch-m oldname newname7. Label management

Tag management is relatively simple, and this is just a brief description.

# create tag v1.0git tag v1. Check tag git tag# delete tag v1.0git tag-d v0. Push tag git push origin-- tags# delete remote tag git push origin: refs/tags/v1.0 Thank you for your reading, this is the content of "methods for Building Git Warehouse and Branch Management". After the study of this article I believe that you have a deeper understanding of the method of building Git warehouse and branch management, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.