SOP-handbook
Git Cheat Sheet
如果你学了Git后，工作效率大增，有更多的空闲时间健身看电影，那我的教学目标就达到了。谢谢观看！
1 廖雪峰课程
不要拜读，只摘重点
先看小结，都是精华
廖雪峰课程
1.1 Intro
增量-版本控制的20世纪
Git跟踪并管理的是修改，而非文件
分布式版本控制系统
中央服务器 ： 交换改动
追踪改动
1. windows 自带的记事本
千万不要使用Windows自带的记事本编辑任何文本文件。
原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误
2.无法追踪word 具体改动
Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的
1.2 时光机穿梭
- 要随时掌握工作区的状态，使用
git status命令。 - 如果git status告诉你有文件被修改过，用
git diff readme.txt可以查看修改内容。
Notes:
git diff 不加参数,即默认比较工作区与暂存区
git diff HEAD -- readme.txt - 比较工作区文件（readme.txt）和HEAD(最新本地版本库)
1.2.1 版本回退
- HEAD指针（git 用C语言写成）指向的版本就是当前版本。返回上一个版本就是
git reset --hard HEAD^ - Git允许我们在版本的历史之间穿梭，使用命令
git reset --hard commit_id - 穿梭前，用
git log可以查看提交历史，以便确定要回退到哪个版本。 - 要重返未来，用
git reflog查看命令历史，以便确定要回到未来的哪个版本。
在Git中，用HEAD表示指向当前版本的指针（git 用C语言写成），也就是最新的提交1094adb...（SHA1 生成的commit id），
Notes: Git 本质是一个链表
1.2.2 工作区和暂存区
工作区（Working Directory）
你在电脑里能看到的目录
版本库（Repository）
暂存区Stage是Git非常重要的概念
隐藏目录
.git，是Git的版本库
stage+ master branch
1.2.3 管理修改
Git是如何跟踪修改的，每次修改，如果不用git add到暂存区，那就不会加入到commit中。
1.2.4 撤销修改
场景1： 当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- 。
场景2： 当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景3： 已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
1.2.5 删除文件
Notes:先手动删除文件，然后使用git rm 和git add效果是一样的。
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
1.3 远程仓库
分布式版本控制系统 Git
杀手级功能之一：远程仓库
中央交换服务器
找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交
1.3.1 git push
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
远程库的名字就是
origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了
GitHub允许你添加多个SSH Key
一台电脑一个key
在GitHub上免费托管的Git仓库，任何人都可以看到
一个是交点保护费，让GitHub把公开的仓库变成私有的
另一个办法是自己动手，搭一个Git服务器,
公司内部开发必备
1.3.2 git clone
要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
1.4 分支管理
分支就是科幻电影里面的平行宇宙
既安全，又不影响别人工作
Git 鼓励使用分支
Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
1.4.1 创建与合并分支
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch
切换分支：git checkout
新版本git优先使用 git switch ，更容易理解
Git 2.23 发布，两个新命令 'git switch'和'git restore'
git update-git-for-windows
创建+切换分支：git checkout -b
merge合并某分支到当前分支：git merge dev
to do ：先切换到maser分支(当前分支)，再merge
删除分支：git branch -d
HEAD 指向当前分支
master指向最新的提交
神奇的指针
Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！
Step1: 把HEAD指向dev
Step2: 新提交一次后，dev指针往前移动一步
Step3: 把dev合并到master上
Step4: [可选]删除dev分支
Step5：切换分支
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
1.4.2 解决合并冲突
查看冲突内容
$ cat readme.txt
* * *
Git is a version control system.
Git is free software.
Git is better.
Creating a new branch is quick
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
我们修改txt文件后如下后保存：
Creating a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"现在，master分支和feature1分支变成了下图所示：
用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit
最后，删除feature1分支：$ git branch -d feature1
1.4.3 分支管理策略
git merge –no-ff
Demo: git 的 merge 与 no-ff merge 的不同之处
Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
git merge –no-ff可以保存你之前的分支历史。能够更好的查看 merge历史，以及branch 状态。
既然廖老师一直谈到指针，那么这里的--no--ff 模式其实就是相当于master指针new了一个跟dev指针一样的空间并且放了相同的内容然后指向这个空间。而原来的快速模式，就是简单将master指针指向dev指针指向的内容而已，并没有自己创造空间。
git merge 则不会显示 feature，只保留单条分支记录。
分支管理策略
实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
1.4.4 Bug 分支
每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，
然后去修复bug，修复后，再git stash pop，回到工作现场；
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
SOP | 如何修复master的bug
1.先在dev分支上创建分支issue-101
2.在issue-101分支上修复
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 1012.git stash 保护dev现场
3.切换到 master分支
4.git cherry-pick 4c805e2(issue-101的commit id)
5.修复后回到dev分支，再git stash pop，回到工作现场
1.4.5 Feature 分支
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支
开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。
1.4.6 多人协作
[SOP] By Neo
1.[dev] git commit -m "add new env"
git pull为什么不直接push？
容易推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
3.git branch --set-upstream-to=origin/dev dev
git pull可能也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
再次
git pull这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：
5.如果有分叉，使用git rebase
6.git push origin dev
小结 by 廖雪峰
因此，多人协作的工作模式通常是这样：
- 首先，可以试图用
git push origin推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin推送就能成功！ - 如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令
git branch --set-upstream-to。origin/
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
- 查看远程库信息，使用
git remote -v； - 本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用
git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；远程库的名字就是origin
在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name；从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。
并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
1.4.7 Rebase
原则：push 的版本是一条线
Note：仍需实战，深入理解
Rebase - git book
使用场景：
总监说提交不是一条线（提交历史不清晰）（原因是pull后自动merge了别人的提交，产生了分叉，最后自动产生了一个merge后的新的提交版本）
解决办法push前使用rebase（过程就是：先把刚才自己提交版本临时保存，再把版本更新到最新远程，再把临时保存的提交重新提交）
rebase操作可以把本地未push的分叉提交历史整理成直线；rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
===只对尚未推送或分享给别人的本地修改执行变基操作清理历史；
===从不对已推送至别处的提交执行变基操作
情景再现：
git log --graph --pretty=oneline --abbrev-commit
多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。每次合并再push后，分支变成了这样:
1.5 标签管理Tag
标签是指向commit的死指针，分支是指向commit的活指针
Why？
Git有commit，为什么还要引入tag？
- “请把上周一的那个版本打包发布，commit号是6a5819e...”
- “一串乱七八糟的数字不好找！”
- 如果换一个办法：“请把上周一的那个版本打包发布，版本号是v1.2”
- “好的，按照tag v1.2查找commit就行！”
所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起
注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
1.5.1 创建tag
命令git tag 用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令git tag -a 可以指定标签信息；
命令git tag可以查看所有标签。
1.5.2 操作tag
切换标签 git checkout
命令git push origin 可以推送一个本地标签；
命令git push origin --tags可以推送全部未推送过的本地标签；
命令git tag -d 可以删除一个本地标签；
命令git push origin :refs/tags/可以删除一个远程标签。
1.6 自定义Git
1.6.1 忽略特殊文件
- 忽略某些文件时，需要编写
.gitignore； .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
官方demo 参考 - 应对各种编程
文件示例
# Windows:Thumbs.db
ehthumbs.db
Desktop.ini
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
# My configurations:
db.ini
deploy_key_rsa1.6.2 配置别名
manual
用git last就能显示最近一次的提交：
git lg 显示分支图
git co表示checkout，git ci表示commit，git br表示branch
命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：
$ git unstage test.py
有没有经常敲错命令？比如git status？status这个单词真心不好记。如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。
当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch：
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
git config --global alias.last 'log -1'
git config --global alias.unstage 'reset HEAD'配置文件位置
配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件
.gitconfig中：
每个仓库的Git配置文件都放在.git/config文件中
1.6.3 搭建Git服务器
[gitlab]
廖雪峰version - 自建
搭建Git服务器非常简单，通常10分钟即可完成；
要方便管理公钥，用Gitosis；
要像SVN那样变态地控制权限，用Gitolite。
1.7 Git Cheatsheet
Git Cheat Sheet
如果你学了Git后，工作效率大增，有更多的空闲时间健身看电影，那我的教学目标就达到了。谢谢观看！