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  github/YOUR_USERNAME/YOUR_FORK.git (fetch)
origin  github/YOUR_USERNAME/YOUR_FORK.git (push)
b） 添加指向原仓库的upstream：
$ git remote add upstream
github/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
c) 查看origin和upstream
$ git remote -v
origin    github/YOUR_USERNAME/YOUR_FORK.git (fetch)
origin    github/YOUR_USERNAME/YOUR_FORK.git (push)
upstream  github/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch) upstream  github/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)
d）直接从原仓库的master分⽀拉取代码并直接合并代码，其中pull=fetch+merge. git pull upstream master
2. 协同⼯作流程理解和梳理
git使用详解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⽹站上，多⼈协同⼯作的操作⽅式的理解。流程梳理和流程总结式的理解。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。