Git实践记录与总结感悟（一）

Git基础知识

1. 颜色

颜色	描述
红色	未加入版本控制
绿色	已经加入版本控制暂未提交
白色	加入版本控制，已提交，无改动
蓝色	加入版本控制，已提交，有改动
灰色	版本控制已忽略文件

2. 一个总文件下，只有一个.git文件，如果有多个的话，就不会往仓库里推。
3. 一定要有一个.gitignore文件。
4. 如果远程分支的版本高于本地分支的版本，并且是两个人修改的同一份文件，但是修改的行数是不一样的，这里的行数不是修改了多少行，而是修改的具体行数，比如同事修改了第5行和第10行，自己修改了第100行，虽然远程分支版本高于本地分支，但是依然是没有任何冲突的。
5. 当使用git clone 下来的时候，一定要切换成想要的分支，不然就是原来的master分支。或者git clone的时候，就指定自己想要的具体分支。

---

git 工作中常规操作流程

a) git add filename
b) git commit -m “我的提交”
c) git pull 如果有冲突就会提示，然后解决冲突
d) git push

---

git使用的问与答

1. 问题：
   那为什么要先add, 其次在commit，然后在pull，最后再push？如果我pull了，岂不是把自己修改的代码都给覆盖掉了嘛，因为远程没有我改的代码，我pull，岂不是覆盖了我本地改动好的地方了？那我还怎么push？
   答：
   先add,在commit 再 pull 再 push 的情况就是为了应对多人合并开发的情况：
   a) add是为了把修改的文件或者新添加的文件，添加到本地仓库中。

   b) commit 是为了告诉 git, 我这次提交改了哪些东西,不然只是改了但是 git 不知道我修改了,也就无从判断比较;

   c) pull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和自己冲突的那同事进行讨论，最终确定保留谁的代码,然后在 git commit && git pull ,再次 pull 是为了防止再自己与冲突同事协商的时候另同事又提交了一版东西,如果真发生了，流程重复一遍即可,通常没有冲突的时候就直接把文件合并了,不会把代码给覆盖掉 。

   d)出现代码覆盖或者丢失的情况:比如Alice和Bob两人的代码pull的时候，文件版本都是1,Alic在本地提交了2,3并且推送到远程了,Bob 修改文件完成后没有commit 操作,直接 git pull 这个时候 Bob 本地版本已经到3了。Bob 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,而且 A 的代码被覆盖了,所以说都要先 commit 再 pull,最后在push,不然会覆盖代码的。

---

Tag使用记录

1. 查看tag
   git tag
2. 在某个commit上打tag
   git tag v1.0.0 c809ddbf83939a89659e51dc2a5fe183af384233
3. 本地tag推送到远程
   git push origin v1.0.0
4. 删除本地tag
   git tag -d fc-V1.0.0
5. 删除线上tag
   git push origin :refs/tags/ fc-V1.0.0
   注意冒号前有一个空格。

---

如何在Github上协同工作？

1. 建立关系

a) 查看现有远程仓库：

$ git remote -v
origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)

b） 添加指向原仓库的upstream：

$ git remote add upstream
https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

c) 查看origin和upstream

$ git remote -v
origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

d）直接从原仓库的master分支拉取代码并直接合并代码，其中pull=fetch+merge.
git pull upstream master

2. 协同工作流程理解和梳理

a) 自己本地仓库，自己githuh远程仓库，对方github远程仓库。

b) 我可以先在本地写好代码。提交到我本地仓库。

c) 然后，我在pull request的时候应该先去合并对方仓库的代码。

d) 然后，我需要把本地仓库的代码，push到我github的仓库上。

e) 最后，我在New pull request。

3. 如何同步对方仓库的代码。

git pull upstream master

这行代码只能把对方仓库中的代码拉取到本地仓库而已

4. github协同工作小结

1. 理解，自己本地仓库肯定是和自己的github远程仓库建立关系。然后本地又需要和源github（远程别人的github仓库）建立关系。然后理解它就很简单了，自己的githup远程仓库和源githup远程仓库想象成两个分支，中间桥梁就是自己本地分支。由自己本地分支去交互自己的githup远程仓库和源github远程仓库。合并了最新的代码后，就直接去githup网站，New pull request就行了。
2. 它的工作原理其实跟自己玩的时候一样的，我在自己的远程仓库中建立了无数个分支。假如我本地的分支跟远程分支是一一对应的。然后我本地仓库作为中间桥梁，不停地去合并别的分支的代码到本地，然后push到远程仓库分支（push前是需要先进行pull操作的）。他们唯一的区别就是，一个直接在本地就可以完成分支合并，但是合并的结果也还是在本地，需要push一下。Githup的工作模式是，我本地仓库作为中间桥梁去pull源githup上的最新代码并合并到本地分支，然后在把最新代码push到自己的远程仓库中，然后最后一步就是New pull request即可。

---

小结

1. 从记录git最基础知识颜色，到实践中的心得体会，比如一定要有一个.gitignore文件，git冲突判断标准是否有多个人修改了同一个文件同一行。
2. 梳理git使用的常规流程。并通过问与答的方式理解了add,commit,pull,push指令的含义。
3. 记录tag使用的常使用指令。
4. 梳理在githup网站上，多人协同工作的操作方式的理解。流程梳理和流程总结式的理解。