Git commit/pull/push的操做步骤

1.操做步骤须要严格执行以下顺序：commit->pull->push

2.commit：将代码提交到本地仓库。

3.pull：将远程仓库代码同步到本地仓库。如遇冲突，解决冲突，重复commit->pull，直到没有冲突。

4.push:将本地仓库代码提交到远程仓库。

 具体讨论以下：

1. 本地和远程的关系至关于两个分支,你感受同样是由于你git pull 的时候已经自动给绑定好对应关系了, set-upstream..balbala

2. 你远程新建了一个分支拉到本地的道理是同样的,属于复制了一份,可是本地分支和远程分支已是两个东西了

3. 本地分支属于本地仓库里,是包含关系,一个仓库里能够有不少分支, 若是是 tag 的话能够分离出独立的仓库

4. 确定不会全量推送到远程的,是经过对比 commit 的记录,若是本地高于远程就直接把多出来的commit 给怼上去,若是本地的这几个 commit 和远程的 commit 有冲突的部分就merge,而后根据提交时间排序再新建一个merge 的 commit 记录再怼上去

5. 这个先 commit 再 pull 再 push 的状况就是为了应对多人合并开发的状况,

   1. commit 是为了告诉 git 我此次提交改了哪些东西,否则你只是改了可是 git 不知道你改了,也就无从判断比较;

   2. pull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操做进行对比的,若是同时操做了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就须要先把和你冲突的那我的拉过来问问保留谁的代码,而后在 git add && git commit && git pull 这三连,再次 pull 一次是为了防止再大家协商的时候另外一我的给又提交了一版东西,若是真发生了那流程重复一遍,一般没有冲突的时候就直接给你合并了,不会把你的代码给覆盖掉

   3. 出现代码覆盖或者丢失的状况:好比A B两人的代码pull 时候的版本都是1,A在本地提交了2,3而且推送到远程了,B 进行修改的时候没有commit 操做,他先本身写了东西,而后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,并且 A 的代码被覆盖了,因此说全部人都要先 commit 再 pull,否则真的会覆盖代码的

6. 两个互相合并的惟一区别就是 A->B 的时候 B 分支上会产生一个 merge_commit 的信息,这个时候 B 是合并状态而 A 未合并状态,若是如今没有发生任何改动执行 B->A 就直接切换过去了,连 merge_commit 都不会生成了

好比你从一个git log为1,2,3,4,5,6的远程库拉取到了本地,
另外一个同事也拉取了一样的代码,并且你的同事先于你提交到远程了,
此时远程的版本是1,2,3,4,5,6,7_new,8_new,
而你当前只是本地的版本1,2,3,4,5,6,7_local,8_local,9_local
从这里你就能看出你前一部分和远程的同样,后一部分和远程的不同,
这个时候你不能正常推送上去的,若是你采起git push origin master --force
那么远程的版本就变成了1,2,3,4,5,6,7_local,8_local,9_local
以前你同事推送的7_new,8_new这两次推送被覆盖了,这不是你们想要的状况
所以须要git pull来将本地的版本合并成这样1,2,3,4,5,6,7_new,7_local,8_local,8_new,9_local,10_commit_merge
远程和本地的排序是按当时 commit 的时间来排的,最后一个10_commit_merge就是你本地和远程合并的标志,最后你推送到远程仓库的应该也是这个,
由于大家操做的是同一个库始终要保持代码的同步,因此一旦版本库发生改动同一分支下的全部人都要跟着去同步他,由于各开发各的直接往上推 git 还没智能到帮你处理冲突的地步