git - Why commit first, then pull, and finally push? Instead of committing and then pushing directly?

Question

I really don’t understand, and there is no clear explanation of this on the Internet.
The situation is like this. Now there is a remote warehouse and only one branch, which is master. Then my local warehouse is cloned from the remote master. Everyone clones it, then changes it locally, commits it, then pulls it and then pushes it. This is what everyone does. So now comes the question:

1, then my local one can be considered a branch? Or is it just a local warehouse?

2. If I create a new branch remotely and then pull it, do I have a branch locally? Is my local branch the same as the remote newly created branch?

3. What is the difference between a local warehouse and a local branch?

4. Commit is submitted to the local warehouse and then pushed. Does this push push all the code to the remote warehouse, or just push the commit to the remote warehouse?

5, then why do you need to commit first, then pull, and then push? If I pulled, wouldn’t it mean that all the code I changed was overwritten? Because there is no code that I changed remotely, so if I pulled, wouldn’t it be overwriting? Have you found the good parts of my local changes? Then how can I push?

6, two branches, A and B, A merges with B and B merges with A, is there any difference?

Answer 1

Insights

1. The local computer is considered a clone.

2. Yes, if there is a branch dev remotely, then pull origin dev, there will be a dev branch locally.

3. The warehouse is the entire project, and the branch is one of the production lines. Just like Alibaba Group does not only have one Taobao

4. push will analyze, of course not all, you can test it yourself and get some large files. The push of a new project for the first time will be very slow. If you add a text of several kilobytes, the transfer will be very fast

5.commit prevents the remote from directly overwriting your local. As long as there are modifications, you will be asked to commit. The reason for prompting you to pull is because the latest things in your remote are inconsistent with your local. Git knows that the things in the remote branch cannot be discarded, so let You pull it and save it locally, so that the local one becomes the latest and finally push it up. In the same way, if your local one is the latest, it will modify the remote one.

Answer completed, okay

Answer 2

1. First pull不会把你本地代码覆盖掉，而是提醒merge冲突，需要你手动merge;

2. Why do you need to pull？因为对你来说你本地可能有个分支，你在这个分支上面工作，那么也有可能存在其他人和你一样的做法，也许你们的代码有依赖又或是有冲突，你肯定不能在mastertest inside? You have to make sure your branch has the latest code;

3. The local branch code is not necessarily consistent with the local warehouse. You submit the local code before it is saved in the local warehouse. It is equivalent to the local branch being a platform for your development, but the final storage address of the developed output is local Warehouse

Both are possible, but most people choose to do it firstpull，因为你没提交你的代码，别人提交了，这时候git会自动merge，而如果你提交了，有时候git自动merge会报冲突，选择先pull就是图一个方便和省事，当然也有人选择先push在pull so that they can understand other partners’ changes to the code

To put it in layman’s terms, it turns out master的代码快照是1，你的同伴改了提交了是2，你的提交代码是3，如果你先pull，那么就是3和1merge，而3包含1，git选择最新代码3覆盖1，不存在冲突关系，而你先push在pull，那就是2和3merge，这是git自动merge will go wrong because he doesn’t know what is needed and what is not

merge problem
The merge of a and b is the same as the merge of b and a. The code required by the two branches is retained and integrated into a code that everyone agrees on

The only difference is that the merge process may be a little different. This depends on the situation, but it is basically the same

Answer 3

1. The relationship between local and remote is equivalent to two branches. You feel the same because the corresponding relationship has been automatically bound when you set-upstream..balbalagit pull

2. The reason why you create a new branch remotely and pull it locally is the same. It is a copy, but the local branch and the remote branch are two different things

3. The local branch belongs to the local warehouse and is an inclusion relationship. There can be many branches in a warehouse. If it is a tag, it can be separated into an independent warehouse

4. It will definitely not be pushed to the remote in full. It is done by comparing the commit records. If the local is higher than the remote, just add the extra

   , and then sort according to the submission time and create a new merge commit record and upload it commit 给怼上去,如果本地的这几个 commit 和远程的 commit 有冲突的部分就merge

5. This situation of committing first, then pulling and then pushing is to deal with the situation of multiple people merging development,

   1. is to tell git what I changed in this submission, otherwise you just changed it but git doesn’t know that you changed it, so there is no way to judge and compare;commit

   2. In these three consecutive rounds, pull again is to prevent another person from submitting another version of things while you are negotiating. If this happens, repeat the process. Usually if there is no conflict, it will be merged directly for you. Your code will not be overwrittenpull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和你冲突的那个人拉过来问问保留谁的代码,然后在 git add && git commit && git pull

   3. Code coverage or loss occurs: For example, when A and B pull the code, the versions are both 1. A submitted 2 and 3 locally and pushed them to the remote. When B made modifications, there was no

      operation. He first did it himself I wrote something, and then commit 操作,他先自己写了东西,然后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push At this time, the local version of B has reached 3. When B changed the code written by A when the local version was 3, and then performed git commit && git push, then in the remote version The answer is 4, and the code of A is covered, so everyone must commit first and then pull, otherwise the code will really be covered