- One: What is Git?
- Two: What is the main difference between SVN and Git?
- 3. How to install Git on Windows?
- Four: How to operate?
- Four: Git undo modify and delete file operations
- Five: remote warehouse
- Six: Create and merge branches
- Seven: bug branch
- Eight: multi-person collaboration
One: What is Git?
Git is currently the most advanced distributed version control system in the world.
Working principle/process:
- Workspace: Workspace
- Index / Stage: temporary storage area
- Repository: warehouse area (or local warehouse)
- Remote: remote warehouse
Two: What is the main difference between SVN and Git?
SVN is a centralized version control system. The version library is centralized on the central server. When working, you use your own computer, so you must first get the latest version from the central server, and then work. Finally, you need to push the work you have done to the central server. The centralized version control system must be connected to the Internet to work. If it is OK in the local area network, the bandwidth is large enough, and the speed is fast enough. If it is under the Internet, if the network speed is slow, it will be confusing.
Git is a distributed version control system, so it does not have a central server. Everyone's computer is a complete version library. In this way, there is no need to connect to the Internet when working, because the versions are all on their own computers. Since everyone's computer has a complete repository, how can multiple people collaborate? For example, if you change file A on your computer, and someone else changes file A on your computer, at this time, the two of you only need to push your changes to each other, and then you can see each other's changes.
3. How to install Git on Windows?
msysgit is the Windows version of Git, as follows:
You need to download one from the Internet, and then install it by default. After the installation is complete, find "Git --> Git Bash" in the start menu, as follows:
A similar command window will pop up, indicating that Git is installed successfully. as follows:
After the installation is complete, the last step is to set up, enter the following on the command line:
Because Git is a distributed version control system, you need to fill in the user name and email address as an identifier.
Note: git config --global parameter, with this parameter, means that all Git warehouses on your machine will use this configuration, of course, you can also specify a different user name and email address for a certain warehouse.
Four: How to operate?
One: Create a repository.
What is a repository? The version library is also known as the warehouse, and the English name is repository. You can simply understand a directory. All files in this directory can be managed by Git. Git can track the modification and deletion of each file, so that it can be tracked at any time. history, or at some point in the future the file can be "reverted".
So creating a version library is also very simple, as follows, I am D drive –> create a new testgit version library under the directory of www.
The pwd command is used to display the current directory.
Use the command git init to turn this directory into a warehouse that git can manage, as follows:
At this time, there will be a .git directory under your current testgit directory. This directory is used by Git to track and manage the version. Don’t manually change the files in this directory, otherwise, the git warehouse will be destroyed. as follows:
Let's take a look at the demo as follows:
I created a new notepad file readme.txt in the version library testgit directory with the following content: 11111111
Step 1: Use the command git add readme.txt to add to the temporary storage area. as follows:
If it is the same as above, there is no prompt, indicating that it has been added successfully.
Step 2: Use the command git commit to tell Git to submit the file to the warehouse.
Now that we have submitted a readme.txt file, we can use the command git status to check whether there are any unsubmitted files, as follows:
It means that there are no unsubmitted files, but I will continue to modify the content of readme.txt. For example, I add a line of 2222222222 below, and continue to use git status to view the results, as follows:
The above command tells us that the readme.txt file has been modified, but the modification has not been committed.
Add the file to the repository.
First of all, it must be clear that all version control systems can only track changes to text files, such as txt files, web pages, codes of all programs, etc. Git is not an exception. The version control system can tell you every change, but the picture , the video binary files, although they can also be managed by the version control system, but there is no way to track the changes of the files. We can only string together each change of the binary files, that is, we know that the picture has changed from 1kb to 2kb, but what has changed? , version control doesn't know either.
Next, I want to see what has been changed in the readme.txt file, how to check it? You can use the following commands:
git diff readme.txt is as follows:
As can be seen above, the content of the readme.txt file has been changed from one line 11111111 to two lines and a line 22222222 has been added.
After knowing what modifications have been made to the readme.txt file, we can submit it to the warehouse with confidence. Submitting the modification is the same as submitting the file in 2 steps (the first step is git add and the second step is: git commit).
as follows:
Two: Version rollback:
As above, we have learned to modify the file, now I continue to modify the readme.txt file, and add another line
The content is 33333333333333. Continue to execute the command as follows:
Now I have modified the readme.txt file three times, so I want to check the history, how to check it? We can now demonstrate using the command git log as follows:
The git log command displays the display logs from the nearest to the farthest. We can see the last three submissions. The latest one is the addition of 333333. The last time was the addition of 222222, and the first default is 111111. If the above display If there is too much information, we can use the command git log –pretty=oneline to demonstrate as follows:
Now I want to use the version rollback operation. I want to roll back the current version to the previous version. What command should I use? You can use the following two commands, the first one is: git reset --hard HEAD^ Then if you want to go back to the previous version, just change HEAD^ to HEAD^^ and so on. If you want to go back to the first 100 versions, it is definitely inconvenient to use the above method. We can use the following simple command to operate: git reset --hard HEAD~100. The content of readme.txt before rollback is as follows:
If you want to roll back to the previous version, the command is as follows:
Let’s check the content of readme.txt as follows: View by command cat readme.txt
As you can see, the content has rolled back to the previous version. We can continue to use git log to view the history information, as follows:
We have seen that the content of 333333 has been added and we have not seen it, but now I want to go back to the latest version, such as: how to restore the content of 333333? We can roll back through the version number, using the command method as follows:
git reset --hard version number, but the problem now is if I have turned off the command line once or the version number of the 333 content, I don’t know it? How do you know the version number for adding 3333 content? The version number can be obtained through the following command: git reflog The demonstration is as follows:
From the above display, we can know that the version number of the added content 3333 is 6fcfc89. We can now command
git reset --hard 6fcfc89 to restore. The demonstration is as follows:
You can see that it is the latest version.
Three: Understand the difference between the work area and the temporary storage area?
- Workspace: It is the directory you see on your computer, such as the files in testgit under the directory (except for the .git hidden directory repository). Or the directory files that need to be created in the future, etc. all belong to the category of the work area.
- Repository: The workspace has a hidden directory .git, which does not belong to the workspace, but this is the repository. There are many things stored in the version library, the most important of which is the stage (temporary storage area), and Git automatically created the first branch master for us, and a pointer HEAD pointing to the master.
We said earlier that using Git to submit files to the repository has two steps:
- It is to use git add to add files, which is actually to add files to the temporary storage area.
- Using git commit to submit changes is actually submitting all the contents of the temporary storage area to the current branch.
Let's continue to use the demo to demonstrate:
We add another line to readme.txt with the content 4444444, and then create a new file in the directory named test.txt with the content of test. We first use the command git status to check the status, as follows:
Now we use the git add command to add both files to the temporary storage area, and then use git status to view the status, as follows:
Then we can use git commit to submit to the branch at one time, as follows:
Four: Git undo modify and delete file operations
One: Undo the modification:
For example, I now add a line of 555555555555 in the readme.txt file, let's check it through the command as follows:
Before I submitted it, I found that the content of adding 5555555555555 was wrong, so I had to restore the previous version immediately, and now I can make changes in the following ways:
- If I know that I want to delete those contents, I can directly change and delete the required files manually, then add them to the temporary storage area, and finally commit them.
- I can go straight back to the previous version the way I used to. Use git reset --hard HEAD^
But now I don't want to use the above two methods, I want to use the undo command directly, how to do it? First of all, before doing undo, we can use git status to check the current status. As follows:
It can be found that Git will tell you that git checkout -- file can discard the modification of the workspace, as follows:
git checkout -- readme.txt, as follows:
The command git checkout --readme.txt means to undo all the modifications made in the workspace to the readme.txt file. There are two situations here, as follows:
- After readme.txt is automatically modified, it has not been placed in the temporary storage area, and it will return to the same state as the version library after using the undo modification.
- The other is that readme.txt has been put into the temporary storage area, and then modified, and the modification will return to the state after adding the temporary storage area.
For the second case, I think we will continue to do the demo to see, if I add a line of content 6666666666666 to readme. It returns to the state after the staging area. As follows:
Note: The command git checkout -- -- in readme.txt is very important, if there is no --, then the command becomes to create a branch.
Two: delete the file
If I now add a file b.txt to the testgit directory of the repository, and submit it. as follows:
As above: In general, you can delete the file directly in the file directory, or use the above rm command: rm b.txt, if I want to completely delete this file from the repository, I can execute the commit command to submit it , now the directory looks like this,
As long as there is no commit before, what should I do if I want to restore this file in the repository?
You can use the command git checkout -- b.txt as follows:
Let's take a look at our testgit directory and add 3 files. As follows:
Five: remote warehouse
Before understanding, register a github account first. Since the transmission between your local Git warehouse and the github warehouse is encrypted by SSH, a little setting is required:
Step 1: Create an SSH Key. In the user's home directory, check if there is a .ssh directory. If so, check if there are two files id_rsa and id_rsa.pub in this directory. If yes, skip the following command directly. If not , open the command line, and enter the following command:
ssh-keygen -t rsa –C “[email protected]”, because I have run it locally before, so I have it locally, as shown below:
id_rsa is the private key, which cannot be leaked out, and id_rsa.pub is the public key, which can be told to anyone with confidence.
Step 2: Log in to github, open the SSH Keys page in "settings", then click "Add SSH Key", fill in any title, and paste the content of the id_rsa.pub file in the Key text box.
Click Add Key and you should see the added key.
How to add remote library?
The current situation is: after we have created a Git warehouse locally, we want to create a Git warehouse in github, and hope that the two warehouses can be synchronized remotely, so that the github warehouse can be used as a backup, and other people can pass through the warehouse to collaborate.
First, log in to github, and then find "create a new repo" in the upper right corner to create a new warehouse. as follows:
Fill in testgit in the Repository name, keep the default settings, and click the "Create repository" button to successfully create a new Git repository:
At present, the testgit warehouse on GitHub is still empty. GitHub tells us that we can clone a new warehouse from this warehouse, or associate an existing local warehouse with it, and then push the contents of the local warehouse to GitHub. storehouse.
Now, we run the command under the local testgit warehouse according to GitHub's prompt:
git remote add origin https://github.com/tugenhua0707/testgit.git
All as follows:
To push the content of the local library to the remote, use the git push command to actually push the current branch master to the remote.
Since the remote library is empty, when we push the master branch for the first time, we add the –u parameter, Git will not only push the content of the local master branch to the remote new master branch, but also push the local master branch and the remote The master branch can be associated to simplify the command when pushing or pulling in the future. After the push is successful, you can immediately see on the github page that the content of the remote library is exactly the same as that of the local one. The user name and password to enter github are as follows:
From now on, as long as the commit is made locally, you can pass the following command:
git push origin master
Push the latest modification of the local master branch to github, and now you have a real distributed version library.
How to clone from remote repository?
Above we learned how to associate a remote library when there is a local library first and then a remote library.
Now we think, if the remote library has new content, how do I clone it locally if I want to clone it?
First, log in to github and create a new warehouse named testgit2 as follows:
As follows, we see:
Now that the remote repository is ready, the next step is to clone a local repository using the command git clone. As follows:
Then the testgit2 directory is generated in my local directory, as follows:
Six: Create and merge branches
In the version backfill, you already know that for each commit, Git strings them into a timeline, and this timeline is a branch. So far, there is only one timeline. In Git, this branch is called the main branch, the master branch. Strictly speaking, HEAD does not point to the submission, but to the master, and the master points to the submission. Therefore, HEAD points to the current branch.
First, let's create a dev branch, and then switch to the dev branch. Do as follows:
The git checkout command plus the –b parameter means to create and switch, which is equivalent to the following two commands
- git branch dev
- git checkout dev
git branch View branches, all branches will be listed, and an asterisk will be added in front of the current branch. Then we continue to do the demo on the dev branch, for example, we now add another line 7777777777777 in readme.txt
First of all, let's check the content of readme.txt, and then add the content 77777777, as follows:
Now the dev branch work has been completed, now we switch to the main branch master, and continue to view the readme.txt content as follows:
Now we can merge the contents of the dev branch into the branch master. On the master branch, use the following command git merge dev as shown below:
The git merge command is used to merge the specified branch to the current branch. After merging, check the readme.txt content. You can see that it is exactly the same as the latest submission of the dev branch.
Noticing the Fast-forward information above, Git told us that this merge is in "fast-forward mode", that is, the master is directly pointed to the current commit of dev, so the merge speed is very fast.
After the merge is complete, we can then delete the dev branch, as follows:
Summarize the commands for creating and merging branches as follows:
- View branch: git branch
- Create a branch: git branch name
- Switch branch: git checkout name
- Create + switch branch: git checkout –b name
- Merge a branch into the current branch: git merge name
- Delete branch: git branch –d name
How to resolve conflicts?
Next, let's go step by step, first create a new branch, for example, the name is fenzhi1, add a line of content 8888888 in readme.txt, and then submit, as shown below:
Similarly, we now switch to the master branch and add content to the last line, which is 99999999, as shown below:
Now we need to merge fenzhi1 on the master branch, as follows:
Git uses <<<<<<<, =======, >>>>>>> to mark the content of different branches, where <<<HEAD refers to the content modified by the main branch, >>>>> fenzhi1 refers to the content modified on fenzhi1, we can modify it as follows and save it:
If I want to check the branch merge situation, I need to use the command git log. The command line demonstration is as follows:
branch management strategy
Usually, when merging branches, git generally uses the "Fast forward" mode. In this mode, after deleting the branch, the branch information will be lost. Now we use the parameter --no-ff to disable the "Fast forward" mode. First, let's do a demo demonstration:
- Create a dev branch.
- Modify readme.txt content.
- added to the staging area.
- Switch back to the main branch (master).
- To merge the dev branch, use the command git merge –no-ff -m "comment" dev
- view history
Screenshot below:
Branching strategy: First of all, the main branch of master should be very stable, that is, it is used to release new versions. In general, it is not allowed to work on it. In general, work is done on the newly created dev branch. After finishing work, for example To be released, or the dev branch code can be merged into the main branch master after it is stable.
Seven: bug branch
In development, you will often encounter bugs, so if you have a bug, you need to fix it. In Git, branches are very powerful. Each bug can be fixed through a temporary branch. After the fix is completed, merge the branch, and then The temporary branch is deleted.
For example, when I receive a 404 bug during development, we can create a 404 branch to fix it, but the work on the current dev branch has not been submitted yet. For example as follows:
It's not that I don't want to submit, but halfway through the work, we still can't submit. For example, my branch bug needs to be completed in 2 days, but my issue-404 bug needs to be completed within 5 hours. How to do it? Fortunately, Git also provides a stash function, which can "hide" the current work site, and continue working after restoring the site later. as follows:
So now I can fix bugs by branching issue-404.
First of all, we need to determine which branch to fix the bug. For example, I am fixing it on the main branch master. Now I want to create a temporary branch on the master branch. The demonstration is as follows:
After the repair is complete, switch to the master branch, complete the merge, and finally delete the issue-404 branch. The demonstration is as follows:
Now, we're back to working on the dev branch.
The work area is clean, so where do we go on the job site? We can use the command git stash list to view it. as follows:
The work site is still there. Git has stored the stash content somewhere, but it needs to be restored. You can use the following two methods:
- git stash apply recovery, after recovery, the stash content is not deleted, you need to use the command git stash drop to delete.
- Another way is to use git stash pop to delete the stash content while restoring.
The demonstration is as follows
Eight: multi-person collaboration
When you clone from a remote repository, Git actually automatically associates the local master branch with the remote master branch, and the default name of the remote repository is origin.
- To view the information of the remote library use git remote
- To view the details of the remote repository use git remote –v
Demonstrated as follows:
One: push branch:
Pushing a branch is to submit all the local files on the branch to the remote library. When pushing, you must specify the local branch, so that Git will push the branch to the remote branch corresponding to the remote library: Use the command git push origin master
For example, the readme.txt code on my current github is as follows:
The local readme.txt code is as follows:
Now I want to push the locally updated readme.txt code to the remote library, using the following command:
We can see the above, the push is successful, we can continue to screenshot the readme.txt content on github as follows:
You can see that the push is successful. If we want to push to other branches, such as the dev branch, we still have the command git push origin dev
So in general, which branches should be pushed?
The master branch is the main branch, so it must be synchronized with the remote at all times.
Some bug fix branches do not need to be pushed to the remote, they can be merged into the main branch first, and then the main branch master is pushed to the remote.
Two: Grab the branch:
When multiple people collaborate, everyone will push their own modifications to the master branch. Now we can simulate another colleague, which can be cloned on another computer (be careful to add the SSH key to github) or another directory on the same computer, and create a new directory named testgit2
But first I want to push the dev branch to the remote as well, as follows
Then enter the testgit2 directory and clone the remote library to the local, as follows:
Now the directory is generated as follows:
Now if our friends want to develop on the dev branch, they must bring the remote origin's dev branch to the local, so they can use the command to create a local dev branch:
git checkout –b dev origin/dev
Now friends can do development on the dev branch, and when the development is completed, push the dev branch to the remote library.
as follows:
The friends have pushed the submission to the origin/dev branch, and I have also modified the same file in the same place in my directory file, and when I try to push it to the remote library, it is as follows:
From the above, we can see that the push failed because my friend’s latest submission conflicted with what I tried to push. The solution is also very simple. The above has reminded us to use git pull to grab the latest submission from origin/dev first. Then merge locally, resolve conflicts, and push.
The git pull also failed because the link between the local dev branch and the remote origin/dev branch was not specified. According to the prompt, set the link between dev and origin/dev: as follows:
This time the git pull is successful, but there is a conflict in the merge, which needs to be resolved manually. The solution is exactly the same as the conflict resolution in branch management. After solving, submit and push again:
We can take a look at the content of readme.txt first.
Now that the manual has been solved, I need to submit it again, and then push it to the remote library. As follows:
Therefore: the multi-person collaborative work mode generally looks like this:
- First, try pushing your own changes with git push origin branch-name .
- If the push fails, because the remote branch is earlier than your local update, you need to use git pull to try to merge first.
- If the merge has conflicts, you need to resolve the conflicts and commit locally. Then use git push origin branch-name to push.
Reprint: https://zhuanlan.zhihu.com/p/135183491