Git 终极 总结笔记
一.时光机穿梭
git log 打印单行查看
git log --pretty=oneline
在 Git中，用 HEAD 表示当前版本,上一个版本就是 HEAD^，上上一个版本就是 HEAD^^
现在，我们要把当前版本回退到上一个版本，就可以使用 git reset 命令：
git reset --hard HEAD^ 回退到上一个版本
在Git中，总是有后悔药可以吃的。
当你 git reset --hard HEAD^ 回退到 a 版本时，再想恢复到 b 版本，就必须找到 b 的 commit id。
Git提供了一个命令git reflog用来记录你的每一次命令
git reflog
用 git diff HEAD -- readme.txt 命令可以查看工作区和版本库里面最新版本的区别
两种错误情况:
1.写错代码，并且 git add 到暂存区了，但是在 commit 之前发现了，用git status查看一下，修改只是添加到了暂存区，还没有提交，这个时候
git reset HEAD readme.txt（readme.txt是文件名）可以把暂存区的修改撤销掉，重新放回工作区
2.写错代码，git add 了 也 git commit 了，但是还没有 git push 想要撤销本次的 commit
git reset --hard HEAD^
删除文件
首先添加一个新文件
git add test.txt
提交
git commit -m "add test.txt"
提交完 如果直接把本地的文件删了
此时 git 知道我删除了文件 因此，工作区和版本库就不一致了
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm test.txt 删掉，
并且git commit -m "remove test.txt"
现在 文件就从版本库中删除了
---------------------------------------------------
另一种情况删除文件：删除错了 版本库里还有 git checkout --test.txt
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
二.远程仓库
添加远程库
git remote add origin 地址 关联远程库和本地
把本地库的内容推送到远程，用 git push 命令，实际上是把当前分支 master 推送到远程。
由于远程库是空的，我们第一次推送 master 分支时，加上了 -u 参数
Git 不但会把本地的 master 分支内容推送的远程新的master分支
还会把本地的 master 分支和远程的 master 分支关联起来，在以后的推送或者拉取时就可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
git push origin master
删除远程库
如果添加的时候地址写错了，或者就是想删除远程库，可以用
git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息
git remote
然后，根据名字删除，比如删除origin
git remote rm origin
此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。
远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。
三.分支管理
1.创建和合并分支
首先创建 dev 分支 然后切换到 dev 分支
git checkout -b dev
对 read.txt 进行修改 加上一句话 Creating a new branch is quick
提交
git add read.txt
git commit -m "branch test"
现在 dev 分支的工作完成 就可以切换回 master 分支
git checkout master
切换回 master 分支后，再查看一个readme.txt文件，刚才添加的内容不见了！
因为那个提交是在 dev 分支上，而 master 分支此刻的提交点并没有变：
现在，我们把 dev 分支的工作成果合并到 master 分支上：
git merge dev
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
合并完成后，就可以放心地删除dev分支了：
git branch -d dev
2.解决冲突
创建新分支
git switch -c feature1
修改 readme.txt 最后一行 Creating a new branch is quick AND simple.
feature1 进行提交
git add readme.txt
git commit -m "AND simple"
切换到，master分支
Git还会自动提示我们当前 master 分支比远程的 master 分支要超前1个提交。
在 master 分支 把最后一行修改为:Creating a new branch is quick & simple.
然后 master 提交
git add readme.txt
git commit -m "& simple"
现在，master分支和feature1分支各自都分别有新的提交
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
git merge feature1
告诉我们冲突了
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：
Creating a new branch is quick and simple.
再提交
git add readme.txt
git commit -m "conflict fixed"
用git log --graph命令可以看到分支合并图。
合并分支时候可以强制禁用 Fast forward 模式 感觉用不上 暂时没记
3.Bug分支
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug(101)，怎么办？
刚开始在 dev 分支进行工作 然后先在dev
git stash
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
git checkout master
git checkout -b issue-101
然后修复bug 修复完
git add readme.txt
git commit -m "fix bug 101"
修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
git switch master
git merge --no-ff -m "merged bug fix 101" issue-101
现在，是时候接着回到dev分支干活了！
git switch dev
用git stash list命令看看：
恢复有两种方式
git stash apply 恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{0}
cherry-pick
在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
有木有更简单的方法？有！
同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。
注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：
git branch
git cherry-pick 4c805e2
Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2
因为这两个commit只是改动相同，但确实是两个不同的commit
用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。
4.Feature 分支
现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。
git switch -c feature-vulcan
开发完成
git add vulcan.txt
git commit -m "add feature vulcan"
切回dev 准备合并
git swith dev
但是！
就在此时，接到上级命令，因经费不足，新功能必须取消！
虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：
git branch -d feature-vulcan
会提示 该分支还没有合并，强行删除需要用-D
git branch -D feature-vulcan
四.多人协作
git remote 查看远程库的信息
git remote -v 详细信息
推送分支
git push origin master
如果要推送其他分支，比如dev，就改成：
git push origin dev
抓取分支
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
git clone ------
现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：
git checkout -b dev origin/dev
文心解读：【这个命令是在Git版本控制系统中使用的。git checkout -b dev origin/dev 的含义是创建一个新的分支 dev，并将其设置为跟踪远程仓库 origin 中的 dev 分支。这意味着你的本地 dev 分支将会与远程仓库的 dev 分支保持同步。如果远程仓库的 dev 分支有任何新的更改，你可以通过 git pull origin dev 命令将其拉取到你的本地 dev 分支。】
现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：
他：
git add env.txt
git commit -m "add env"
git push origin dev
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：
git add env.txt
git commit -m "add new env"
git push origin dev
这个时候就会告诉你推送失败
因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
先：
git pull
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'. 成功的提示
再 pull
git pull
这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：
git commit -m "fix env conflict"
push origin dev
五.标签管理
1.创建标签
在Git中打标签非常简单，首先，切换到需要打标签的分支上：
git checkout master
然后 git tag <name>就可以打一个标签
git tag v1.0
可以用git tag 查看所有标签
默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
方法是找到历史提交的commit id，然后打上就可以了：
git log --pretty=oneline --abbrev-commit
找到历史记录
git tag v0.9 版本号 (例如f52c633)
查看 git tag
注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
git show v0.9
还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
git tag -a v0.1 -m "version 0.1 released" 1094adb(commit的版本号)
注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
2.操作标签
如果标签打错了，也可以删除：
git tag -d v0.1
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
如果要推送某个标签到远程，使用命令git push origin <tagname>：
git push origin v1.0
或者，一次性推送全部尚未推送到远程的本地标签：
git push origin --tags
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
git tag -d v0.9
然后，从远程删除。删除命令也是push，但是格式如下：
git push origin :refs/tags/v0.9
要看看是否真的从远程库删除了标签，可以登陆GitHub查看。
435
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
