According to different configurations, git pull can be equal to fetch + merge or fetch + rebase. To understand the difference, you first need to understand the git architecture, which is a distributed version management system. Draw a picture, not only related to git fetch and git pull, but also very helpful for overall understanding. as follows:
The figure above shows the overall architecture of git and the main commands related to each part. First, explain the parts involved:
The working directory, in short, is the area where you work. For git, it is the local working directory. The content of the workspace will include the content submitted to the temporary storage area and the version library (current submission point), as well as the content of your own modifications.
The stage area (stage area, also known as index area) is a very important concept in git. It is a transitional stage before we submit the changes to the repository. When viewing the GIT's own help manual, index is usually used to indicate the temporary storage area. There is a .git directory under the working directory, and there is an index file in it, which stores the contents of the temporary storage area. The git add command adds the contents of the workspace to the staging area.
The local repository, the repository of the version control system, exists locally. When the git commit command is executed, the contents of the temporary storage area will be submitted to the warehouse. There is a .git directory under the workspace. The content in this directory does not belong to the workspace. Inside is the data information of the warehouse, and the related content of the temporary storage area is also in it. Here you can also use merge or rebase to merge a copy of a remote warehouse into a local warehouse. Only merge in the figure, note that rebase can also be used here.
The remote repository is basically the same concept as the local repository. The difference is that one exists remotely and can be used for remote collaboration, but the other exists locally. Local and remote interaction can be realized through push/pull;
A remote warehouse copy can be understood as a remote warehouse cache that exists locally. If you need to update, you can get the remote warehouse content through the git fetch/pull command. When fetch is used, it is not merged into the local warehouse. At this time, git merge can be used to merge the remote warehouse copy with the local warehouse. Depending on the configuration, git pull can be git fetch + git merge or git fetch + git rebase. The difference between rebase and merge can be found on the Internet to find out.
Seeing this, it is not only clear about git fetch and git pull. And when we use each command, we can clearly understand what git does at this time.
pull request
Pull request referred to as PR, is the concept of github, not the concept of git, so it does not produce results immediately. Someone needs to agree to complete the PR. Of course, the person who agrees to complete the PR can be yourself or you can reject the PR. For example, for the Linux kernel project, send an email directly to Linus with the subject of Pull Request. Write the git URL and the feature or fix bug you added in the email. If Linus feels ok, it will go to git pull according to the given git url.
Explanation one:
There is a warehouse called Repo A. If you want to contribute code, you must first Fork this Repo, so you have a Repo A2 under your Github account. Then you work under this A2, Commit, push, etc. Then you want the original repository Repo A to merge your work. You can initiate a Pull Request on Github, which means requesting the owner of Repo A to merge the branch from your A2. If it is approved and formally merged, then you will contribute to Project A.
Explanation two:
I try to explain pull reqeust by analogy. Think about our middle school exams and the teacher changing papers. The test paper you make is like a warehouse, and your test paper will definitely have many errors, which is equivalent to a bug in the program. The teacher takes your test paper, which is equivalent to fork first. Make some modification comments on your volume, which is equivalent to git commit. Finally, giving you the revised test paper is equivalent to sending a pull request, and you get the test paper to correct the error again, which is equivalent to a merge.
When you want to correct errors in someone else’s warehouse, you have to go through a process:
- Fork someone else’s warehouse first is equivalent to a copy, because no one will directly ask you to modify the original warehouse
- clone to the local branch and do some bug fixes
- Initiate a pull request to the original warehouse and let him see the bug you modified
- The original warehouse reviews this bug, if it is correct, it will be merged into his own project
At this point, the entire pull request process is over.
summary:
1. Git fetch did not change the code of the local warehouse, but pulled the remote commit data, and updated the commit id of the remote warehouse to latest.
2. You can try to view the .git folder: There are three folders in ./git/refs: heads, remotes, tags. Heads and remotes record the latest commit ids of different local and remote warehouses respectively.
3. What fetch changes is the commit id of the corresponding branch in remotes.