Hello, I am Ma Nongfei ge, thank you for reading this article, welcome one button three lian oh. This paper will first introduce the local GitLab service, and then focus on the common Git commands,Git core concepts and conflict handling, and finally introduce the difference between Git and SVN. If you have any questions or needs, please feel free to leave a message.

1. What is Git?

Git is an open source distributed version control system that can handle project version management from very small to very large projects efficiently and quickly. Git is implemented through C language development.

2. Comparison between Git and SVN

Git and SVN are two completely different version control systems. Git is a distributed version control system, while SVN is a centralized version control system. To compare Git and SVN, you need to understand the basic concepts of distributed version control systems and centralized version control systems. Centralized version control system: a prominent feature is that the version repository is stored on a central server, which centrally manages the version and branch information of a project. Each member of the team needs to pull the latest code from a central server and get to work. When you’re done, submit the code to a central server. Centralized version servers have two disadvantages:

The network must be connected to work, and when there is no network or poor network, the members of the team cannot work together.
Security is poor because the version inventory is kept on a central server, and when the central server fails, the repository is lost, rendering all members inoperable.

The network topology of a centralized version control system is as follows:You can see that all members of the team have work computers that only interact with a central server. If the version library is like a library, then everyone (every computer) needs to borrow the book from the library (pull the latest code), read it and then return it to the library (after modification, submit it to a central server).

Distributed version control systems: The biggest difference from centralized version control systems is thisAll members of the team have a complete repository on their work computers, and there is no central server.This is equivalent to each member of the team having their own small library (version library), and members can exchange books in their library with each other (submitting their own changes to each other). There is no need for a central server to manage and coordinate management. In the actual use of distributed version control systems, repository push is rarely done on computers between two people, because sometimes you are not on the same LAN, or your colleague’s computer is down. Thus, a distributed version control system usually also has a computer that acts as a “central server,” but this server is only used to facilitate the “exchange” of everyone’s changes. Without it, everyone can do just as well, but the exchange of changes is not convenient.The repository on this computer that acts as the “central server” is called the remote repository, and the repository on other member computers is called the local repository. More on that later.

The network topology of a distributed version control system is as follows:

Distributed version control systems eliminate the central server, which embodies the core concept of distribution: decentralization. There are two advantages to this:

Work without Network: Every member of the team can work without network because there is a complete version library locally and there is no need to worry about data loss.
More secure data: It doesn’t matter if one member’s computer crashes, just copy it from another member’s computer. But if the central server of a centralized version control system fails, the repository can be lost, making it impossible for everyone to work.

3. System environment

system	version
Windows	Windows10
Linux	Ubuntu16.04

4. Install the Git client

Git client: Git client: Git client Here is a brief introduction to Git client installation for different operating systems.

Linux system.

First of all bygit --versionCommand to check whether the Git client is installed on your computer.Skip this section if you already have it installed. If not, read on: Linux systems are available in different distributions that can be accessed throughcat /proc/versionCommand to view the Linux version.

Install Git in Debian or Ubuntu

Git can be installed in Debian or Ubuntu using the apt package management tool.

sudo apt-get install git
Copy the code

Install Git in Red Hat or CentOS

In Red Hat or CentOS, you can use the yum package management tool to install Git:

yum install git -y
Copy the code

If you cannot find the yum command, you need to install the yum tool first. See the following command

# delete all files in yum. Repos
rm -f /etc/yum.repos.d/*
# Then re-download Ali's yum source
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
# clear cache
yun clean all
Copy the code

Windows system.

Git Git Git Git Git Git GitGit download address After downloading the installation package, keep clicking Next to install. Again, I won’t repeat it.

5. Perform local version library operations

Git Bash is a command line tool for Git, and Git GUI is a visual tool for Git (which is rarely used).

Create a local version library

The first step is to create an empty folder named git_learn. The second step is to run the git init command in this folder to make it a git manageable repository. After the second step, a hidden folder named.git appears in the git_learn directory, which is the git repository. Do not manually modify anything in the.git folder in case your local repository becomes unavailable.

Once the local version library is set up, you can create a file in the git_learn folder to test. A file named readme.txt is created here. Git add readme. TXT You can commit the readme. TXT file to the staging area with git add readme. TXT (more on the concept of staging area later). If you have more than one file to add, you can run the git add. command. Git’s readme. TXT file must be submitted to the current branch of git’s repository, which is master by default. Git commit -m ‘

‘

Work area and staging area

Two important concepts are workspace and staging (a Git-specific concept). A workspace is a directory (excluding hidden files) that you can see on your computer. For example, the git_learn directory is a workspace.

The staging workspace has a hidden directory, git, which is not a workspace, but a git repository, the most important of which is the staging area.

The first branch Git automatically creates for us is called master, and the pointer to master is called HEAD.

I mentioned workspaces, staging areas,git addCommands andgit comitCommand. So what are they related to each other? Here is a flow chart:The ABC folder in workspace is committed to stage through add command, and the ABC folder in stage is committed to master branch through commit command.

Management of change

Git manages changes, not files. Modification here refers to any operation on the workspace, including new files; Delete files; Modify files and so on. Even adding a sentence or deleting a character in a file counts as a change. For example, use the readme. TXT file as an example:

Add the word gittest to readme.txt for the first time. Then performgit add readme.txtAnd by commandgit statusView the status.

hello world gittest 2. Add a second line to the readme. TXT filegit tracks changes.hello world gittest git tracks changes

Direct executiongit commit -m 'git tracks changes'Command. Then throughgit status You can see that the second change was not committed. This is because the second change was not committed to the staging area first.So we’re going to do thisFirst change -> git add -> Second change -> git commit. When usinggit addAfter the command, the first change in the workspace is put into the staging area, ready to commit, the second change in the workspace is not put into the staging area, so,git commitCommit changes in the staging area only to the current branch. So the second change was not committed.That is, all changes must first be committed to the staging area via git add and then to the current branch via Git commit.. In real development, you would add all the changes together, then commit them together.

Delete the file

How do I delete an obsolete file on the current branch? For example, you want to delete a file named test1.txt. It only takes two lines of command.

git rm test1.txt
git commit -m "remove test.txt"
Copy the code

5.Ubuntu builds a private Git repository

As mentioned above, in practical development, a computer is usually taken as the “central warehouse”, and the computer acting as the central warehouse needs to install a code warehouse software. The open-source software GitLab is selected here, which is an online code warehouse software based on Git and provides a web visual management interface, and can be deployed locally. Typically used for collaborative development within enterprise teams. Of course, if you don’t want to set up your own Git repository, you can just use Github, the largest gay dating site (similar to GitLab). How to install GitLab software on Ubuntu and set up a private Git repository?

Install necessary services

# Update apt sources
sudo apt-get update
Install dependency package, run the command
sudo apt-get install curl openssh-server ca-certificates postfix
sudo apt-get install -y postfix
Copy the code

Then trust GitLab’s GPG public key:

curl https://packages.gitlab.com/gpg.key 2> /dev/null | sudo apt-key add - &>/dev/null  
Copy the code

Configuring a Mirror Path

Because the download speed of foreign countries is too slow, the path of tsinghua University image is configured.

sudo vi /etc/apt/sources.list.d/gitlab-ce.list  
Copy the code

Write the following code in this file

deb https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu xenial main 
Copy the code

Install gitlab – ce

sudo apt-get update
sudo apt-get install gitlab-ce
Copy the code

After successful installation of Gitlab-CE. 5. Change the external URL. Change the external URL to your OWN IP address or domain name in the /etc/gitlab/gitlab.rb configuration file.

sudo vi /etc/gitlab/gitlab.rb
Copy the code

Go to external_url and change its default address to my local LAN IP: 192.168.40.138

external_url 'http://192.168.40.138/'  The local network IP address is 192.168.41.128
Copy the code

Perform the configuration

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

sudo gitlab-ctl reconfigure
Copy the code

Start the GitLab

sudo gitlab-ctl start
Copy the code

Can be achieved byps -ef|grep gitlabCommand to check whether GitLab is started successfully. After the successful startup of GitLab, you can access the homepage of GitLab through the browser. Type in your browserhttp://192.168.40.138/; The default user name and password are root and root respectively. At this point, the installation of GitLab is complete, and we have successfully built our own Git repository.

The use of GitLab

Add user

Click the Settings button to enter the Settings bar and selectUsers->New UserThe page for adding a user is displayed. Enter your name, username, and email address to register and add new users.

Add team

Once the user is added, you add the user to the team. By default, there is a team named GitLab Instance in GitLab. You can also add your own team, so HERE I added 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 to Add User (s) to the group will appear on the right. Add all users in this column to the team. The roles of users are visitor, tester, developer, manager, owner, etc.

Creating a Remote Warehouse

With user and team Settings behind us, it’s time to focus on how to create a new remote repository. It is also more convenient. The operation steps are as follows:Project->Your projects->New project There is a new remote repository named git_test, all of which belong to the AI_edu team.

There are three levels of permissions in the repository: Private(only your team can pull and push codes) and Internal (users outside the blacklist can pull and push codes). Public (all users can pull).

SSH Key configuration (generating public and private keys)

Why is the SSH key configured? This is because GitLab communicates with your computer over SSH. To put it bluntly, you can’t push code to remote libraries if you don’t have an SSH key configured. Here you first generate public and private key files locally, and then copy the contents of the public key file to GitLab.

Configuring a User Name

Git config --global user.name "username"Copy the code

Configure your email

 git config --global user.email  address@gmail.com
Copy the code

address@gmail.com with your actual email address. You don’t need single quotes. 4. Generate public and private keys

ssh-keygen -C 'you email address@gmail.com' -t rsa
Copy the code

If it’s easier, you can just fill it outssh-keygen Command. Email Address You can set the email address. 2 Locate the public key file id_rsa.pub and copy the public key content to GitLab

6. Branch management

Create and merge branches

The concept of branches: A branch is a timeline connected by points created for each commit. This timeline is a branch, and by default there is only one master branch. The HEAD doesn’t technically point to the commit, it points to the master, and the master points to the commit, and the HEAD points to the current branch. Git uses the master branch to point to the latest commit and the HEAD branch to point to the master to determine the current branch and its commit point. Every time you commit, the master branch moves a step forward, so as you commit, the master branch gets longer and longer. Its structure is shown in the figure below:

1. Create dev branch

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

git checkout -b dev
Copy the code

Git checkout with the -b parameter to create and switch to the dev branch is equivalent to the following two commands.

$ git branch dev
$ git checkout dev
Copy the code

Git commit timeline after executing the above command:When code is committed on the dev branch (without changing the master branch), the dev branch is constantly pushed back. The master pointer doesn’t change. git checkoutThe command is a special command. Different parameters have different effects. Such as:git checkout -- fileCommand to undo all changes in the file. So Git also providesgit switchCommand is used to create and switch branches.

Create and switch to a new dev branch
git switch -c dev
Switch to the existing master branch
git switch master
Copy the code

2. View all branches

Once the branch is created, you can use the git branch command to view it.

3. Branch merge

Once the team members have finished developing on the dev branch, they can merge the content on the dev branch to the master branch by pointing the master pointer to dev’s current commit. Git merge branch just changes the pointer, the contents of the workspace remain unchanged.

The merge command 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 the master branch
git checkout master
# merge dev branch
git merge dev
Copy the code

Delete the dev branch

Now the dev branch is merged with the master branch, and the dev branch can be deleted. Git deleting the dev branch is actually deleting the dev pointer. Once deleted, only the master branch is left. Note that you must switch to the master branch before deleting the dev branch. The command for deleting the dev branch is as follows:

git branch -d dev
Copy the code

Resolve the conflict

In the process of teamwork, it is inevitable to encounter various modification conflicts. So how to resolve these conflicts? For example, if you and your colleague have modified the readme.txt file separately, there will be a conflict when you submit it at the same time. Or maybe you changed the readme.txt file on the Master branch and feature1 branch, respectively. So when you merge the Feature1 branch into the Master branch, there’s a conflict. Here’s an example:

Add text to the readme.txt file on the Feature1 branchTo deal with conflict. Then submit to the Feature1 branch.
Switch to the Master branch and add text to the readme.txt file

Conflict Handling The master has a conflictCopy the code

It then commits to the master branch. 3. Merge the Feature1 branch into the Master branch, and there will be merge conflicts. As shown below:

After the conflict, Git marks the contents of the different branches with <<<<<<<, =======, and >>>>>>>. The way to handle conflicts is to edit the conflicting content. Then resubmit.

$git add readme. md $git commit -mCopy the code

Branch Management Strategy

Git usually uses the Fast Forward mode when merging branches. However, in this mode, branch information is discarded when a branch is deleted. As shown in the figure below, after deleting the dev branch, the branch information is lost

If you want to forcibly disable the Fast Forward mode, Git generates a new COMMIT when merging. Branch information is not lost when a branch is deleted. The command is git merge --no-ff -m "merge with no-ff" devReady to merge the dev branch, where--no-ffParameter to disable Fast Forward because this merge is creating a new COMMIT-mParameters. Include the commit description.

Bug branch

When you receive a bug fix code-named 01, naturally, you will create a branch issue – 01 to fix it, but, if this is the work you are on the dev branch has not submitted, submitted to it, but you work in the dev only generally, also can’t submit, is expected to finish still need 1 day time. However, the bug code 01 must now be fixed within two hours. What to do at this point? Don’t you expect a feature to hide your current uncommitted work on Dev and then switch to the issue-01 branch to fix bugs? Your desire to hide your current work site is fulfilled with the Stash feature. As shown in the following figure: Rungit stashAfter the command, the new hello.html file disappears from the workspace.

Preserve work site

git stash
Copy the code

The git stash command hides work that is currently uncommitted. Keep your workspace clean and fresh.

View the work site

The Git Stash list allows you to view all your saved worksites for the current repository.

git stash list
Copy the code

Restoration site

Now that the bug code-named 01 has been fixed, you can continue to switch to the dev branch. The first thing you need to do is restore the work site you saved earlier. The order to restore the work site was:

git stash apply
Copy the code

Delete work site

The work site can be restored with the git Stash apply command. However, the work site remained after the restoration. Then we also need a command to delete the work site. Its orders are:

git stash drop
Copy the code

Restore and delete the work site

A command to restore the work site, another command to delete the work site. It’s a little complicated. Is there a command to merge the two? The answer is: it can be done with the following command:

git stash pop
Copy the code

After fixing the bug on the master branch, we can see that the dev branch was split from the master branch earlier, so the bug actually exists on the current dev branch as well. How do you fix the same bug on the dev branch? Just do it again and submit it, okay? This is not a bad approach, but if the BUG involves too many changes, it can be a bit overstretched. Can we copy BUG fixes to the current dev branch? The answer is:

git cherry-pick  821ea4d
Copy the code

A single commit can be copied to the current branch using the git cherry-pick command. You can view the version number of a committed commit using git log.

Feature branch

When adding a new feature, you don’t want to mess up the main branch with some experimental code, so every time you add a new feature, you should create a new feature branch, develop on it, merge it, and finally remove the feature branch. You can run the git branch -d branchname command to delete branches. However, if you use this command to delete a branch that has not been merged into the master branch, Git will throw an error message indicating that the branch cannot be deleted. A branch named feature-01 is to be deleted. But the branch has not been merged yet. This is where the command to force the branch to be deleted is needed.

git branch -D feature-01
Copy the code

Feature-01 indicates the name of the branch to be deleted. You’re essentially replacing the -d argument with the -d argument.

Remote warehouse (multi-person collaboration)

So much said before, it seems that a person in the local operation, not involved in the case of multi-person collaboration. This is definitely not possible in team development, because we are a team. What are the operations involved when so many people collaborate?

Clone remote repository

GitLab, a private Git repository manager, was built in chapter 3. A repository named git_test is also created. Now all you have to do is clone the remote repository. The command for cloning is git clone

git clone http://192.168.40.138/ai-edu/git_test.git
Copy the code

http://192.168.40.138/ai-edu/git_test.git is the address of the remote warehouse. Of course, the IDEA can also be directly through the graphical interface operation, but also save the process of importing the project. Its operation steps are:

The selectedFile->New->Project from Version Control->Git. As shown below:

2. Fill in the URL with the address of the remote repository and click the Clone button. As shown below: Note that by default only the master branch is cloned, and no other branches are cloned. The other branches need to be pulled using git pull, which will be described later.

Viewing remote branches

You can run the git remote command to view the remote repository. The default branch name of the remote repository is Origin. You can run the git remote -v command to view the detailed information about the remote repository, including its address.

$git remote -v origin http://192.168.40.138/ai-edu/git_test.git (fetch) origin http://192.168.40.138/ai-edu/git_test.git (push)Copy the code

The above shows the address of Origin that can be grabbed and pushed. If you do not have push permission, you cannot see the address of push.

Push the branch

Now that the remote repository is cloned, how do you push all local commits on the current branch to the remote repository? Git push

git push

git push origin master
Copy the code

This statement pushes the local master branch to the remote Origin branch. Git push -u origin master git push -u origin master This is because if the current branch is traced to multiple hosts, you can specify a default host with the -u argument, so you can use Git push without any arguments. So which branches should be consistent with remote branches? It is generally believed that:

The master branch is the primary branch and needs to be synchronized with the remote at all times
The dev branch is the development branch where all the team members work, so remote synchronization is also required
The bug branch is only used to fix bugs locally, so there’s no need to push it remotely unless your boss wants to see how many bugs you fix per week.
Whether the feature branch is pushed to remote depends on whether you work with your friends on it.

To put it bluntly, branches that require teamwork must be pushed to remote libraries or not.

Create a remote branch

Remote branches can also be created using git push.

git push origin dev
Copy the code

Suppose you already have a dev branch locally. The above commands push the dev branch to the remote library and create a remote dev branch.

Pull the branch

You can use the Git pull command to pull data and branch information from a remote repository. Consider the following scenario: your colleague creates a dev branch locally and commits it to a remote repository. You also create a dev library locally that will fail when you push. The results are shown below:

Your colleague’s latest submission conflicts with the submission you are trying to push. The solution is to use Git pull to pull the latest commit from origin/dev, then merge it locally, resolve the conflict, and push it.

$ git pull
There 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 <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> dev
Copy the code

Git pull also failed. The origin/dev branch is not linked to the origin/dev branch.

Associate local and remote branches

$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
Copy the code

Once the local and remote branches are associated, success can be achieved in pull. This time git pull is successful, but there is a conflict in the merge, which needs to be resolved manually. The solution is also to manually process the conflicting files locally. After the resolution, submit and push.

Deleting a Remote Branch

through

git push origin :dev
Copy the code

Command to delete the remote dev branch. However, the local dev branch still exists. Git branch -d dev

See the branch

throughgit branchYou can view the local branch throughgit branch -aYou can view local and remote branches.

Version back

In actual development, we often encounter such a scenario: you mistakenly submitted a piece of bad code, so that other colleagues update the code after the project can not start, what should we do? Our first thought was to roll back the version. Go back to the previous version without any problems.

throughgit logCommand to find all commit logs for the current repository. Then, find the version you need to go back to. As shown below:
Back to previous version:git reset HEAD
Rollback to the specified version:git reset commitIdCommitId is the version number of the specified version. For example, the version information is rolled back tob50c9bdcbf9641d33e4b531bd96dc1f27d4bf602This version. So the command is:

git reset b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602
Copy the code

Back up and pass againgit logView, the latest commit log has becomeHello to submitThis version. Of course, it is much easier to go back and forth through IDEA. Directly in theVersion Control->LogRight-click the version you want to roll back to and select itReset Current Branch to HereCan.

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

7. Label management

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

# create tag v1.0Git tag v1.0# view tags
git tag
# Delete tag v1.0Git v0.1 tag - d# Push tag
git push origin --tags
Delete the remote tagGit push origin: refs/tags/v1.0Copy the code

Insert a picture description here

conclusion

More than 16,000 words, I write tired, you see also tired!! The article presents a few beautiful woman’s photograph to each reader greatly resolves tired. I’ve had a really good liver for two days. And now finally the liver is gone. Hope to be helpful to readers. I’m so tired of reading the text. Here is a picture to make a summary.This diagram clearly shows the basic flow of Git.

I am Mynongfei and thank you again for reading this article.

The whole network with the same name [code nongfei brother]. Thank you again for reading this article.

Git—- from the construction of private Git repository to the use of commands to branch management, the whole process of a full set of service packages you are satisfied with