《Git 教程》-- 廖雪峰 笔记

1. 设置用户名和邮箱
   git config --global user.name "Your Name"
git config --global user.email "[email protected]"
   注意：git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git版本库都会使用这个配置，当然也可以对某个版本库指定不同的用户名和Email地址

2. 创建空的版本库（empty Git repository）
   git init

3. 添加文件到暂存区
   git add

4. 推送到版本库
   git commit -m

5. 初始化一个Git版本库，使用git init命令
   添加文件到Git版本库，分两步：
   使用命令git add ，注意，可反复多次使用，添加多个文件，实际上就是把文件修改添加到暂存区
   使用命令git commit -m 完成，实际上就是把暂存区的所有内容提交到当前分支

6. 查看版本库当前的状态
   git status

7. 查看当前文件与版本库记录的文件的差异
   git diff
   也可以写成下面这样
   git diff /HEAD --
   这样比较灵活

8. 查看日志记录
   git log
   注意：嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数

9. 移动版本库的版本
   git reset --hard HEAD^
   上述语句为使版本库回退到上一个版本，上两个版本即HEAD^^
   也可以写成下面这样
   git reset --hard HEAD~1
   上两个版本即HEAD~2
   也可以指定版本库移动到某一个版本
   git reset --hard
   不用全部输入，只需要输入前7位即可
   注意：在windows的cmd中，^是特殊符号，使用时需要用双引号包住，如"^"

10. 查看版本库的命令执行历史
    git reflog

11. HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard
    穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本
    要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本

12. 为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件

13. 每次修改，如果不用git add到暂存区，那就不会加入到git commit中

14. 复原工作区的修改
    git checkout --
    这里有两种情况：
    一种是文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态
    一种是文件已经添加到暂存区后，又作了修改，现在撤销修改就回到添加到暂存区后的状态
    总之，就是让这个文件回到最近一次git commit或git add时的状态
    命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令

15. 把暂存区的修改回退到工作区，即将暂存区变回跟版本库一样，复原暂存区的修改
    git reset /HEAD

16. 场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout --
    场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作
    场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库

17. 删除版本库中的文件
    git rm

18. 创建SSH Key（在windows下需要打开Git Bash）
    ssh-keygen -t rsa -C "[email protected]"
    你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。如果一切顺利的话，可以在用户主目录里找到ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人
    为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送

19. 关联一个远程库
    git remote add git@server-name:path/repo-name.git

20. 把本地库的内容推送到远程
    git push master
    实际上是把当前分支master推送到远程，如果远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令，例如
    git push -u master

21. 克隆远程库到本地
    git clone
    Git支持多种协议，包括https，但通过ssh支持的原生Git协议速度最快

22. 创建并切换分支
    git checkout -b
    也可以分成两步走
    创建分支
    git branch
    切换分支
    git checkout

23. 查看当前分支
    git branch
    git branch命令会列出所有分支，当前分支前面会标一个*号

24. 切换当前分支
    git checkout

25. 合并指定分支到当前分支
    git merge

26. 删除指定分支
    git branch -d
    若分支没有被合并过，则
    git branch -D

27. 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成
    解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交

28. 查看带分支合并的日志记录图
    git log --graph --pretty=oneline --abbrev-commit

29. 通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
    git merge --no-ff -m
    合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并

30. 分支策略
    在实际开发中，我们应该按照几个基本原则进行分支管理：
    首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
    那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本
    你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了

31. 储藏当前工作现场
    git stash

32. 查看储藏工作现场列表
    git stash list

33. 恢复工作现场
    git stash apply

34. 删除储藏的工作现场列表
    git stash drop

35. 恢复并删除储藏的工作现场
    git stash pop

36. 查看远程仓库的信息
    git remote
    查看远程仓库的详细信息
    git remote -v

37. 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
    git push

38. 抓取分支（创建远程分支到本地）
    git checkout -b /

39. 指定本地分支与远程分支的链接
    git branch --set-upstream-to=/

40. 多人协作的工作模式通常是这样：
    首先，可以试图用git push 推送自己的修改
    如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并
    如果合并有冲突，则解决冲突，并在本地提交
    没有冲突或者解决掉冲突后，再用git push 推送就能成功
    如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to=/
    这就是多人协作的工作模式，一旦熟悉了，就非常简单

41. rebase操作可以把本地未push的分叉提交历史整理成直线
    rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比
    git rebase

42. 打标签
    git tag
    指定打标签的commit id
    git tag
    创建带有说明的标签，用-a指定标签名，-m指定说明文字
    git tab -a -m
    注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签

43. 查看标签
    git tag
    注意，标签不是按时间顺序列出，而是按字母排序的

44. 查看标签信息
    git show

45. 删除标签
    git tag -d
    如果标签已经推送到远程，先从本地删除
    git tag -d
    再远程删除
    git push :refs/tags/

46. 推送标签到远程版本库
    git push
    一次性推送全部尚未推送到远程的本地标签
    git push --tags

47. 删除已关联的远程库：
    git remote rm

48. 忽略特殊文件
    在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名或文件夹填进去，Git就会自动忽略这些文件或文件夹及其子文件
    不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了
    所有配置文件可以直接在线浏览：https://github.com/github/gitignore
    忽略文件的原则是：
    忽略操作系统自动生成的文件，比如缩略图等
    忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件
    忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件

49. 添加已忽略的文件
    git add -f

50. 检查忽略规则
    git check-ignore -v

51. 技巧，优化log显示并简短为 git lg
    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"

52. 分支开发应用示例
    master分支，即主分支。任何项目都必须有个这个分支。对项目进行tag或发布版本等操作，都必须在该分支上进行
    develop分支，即开发分支，从master分支上检出。团队成员一般不会直接更改该分支，而是分别从该分支检出自己的feature分支，开发完成后将feature分支上的改动merge回develop分支。同时release分支由此分支检出
    release分支，即发布分支，从develop分支上检出。该分支用作发版前的测试，可进行简单的bug修复。如果bug修复比较复杂，可merge回develop分支后由其他分支进行bug修复。此分支测试完成后，需要同时merge到master和develop分支上
    feature分支，即功能分支，从develop分支上检出。团队成员中每个人都维护一个自己的feature分支，并进行开发工作，开发完成后将此分支merge回develop分支。此分支一般用来开发新功能或进行项目维护等
    fix分支，即补丁分支，由develop分支检出，用作bug修复，bug修复完成需merge回develop分支，并将其删除。所以该分支属于临时性分支
    hotfix分支，即热补丁分支。和fix分支的区别在于，该分支由master分支检出，进行线上版本的bug修复，修复完成后merge回master分支，并merge到develop分支上，merge完成后也可以将其删除，也属于临时性分支