标签：索引 远程分支 十分 面向 线上游戏 推荐 开始 checkout 修改
git作为一个知名小游戏，在被Linus开发出来后就广受好评，在程序员圈子内迅速传播，以至于现在很多程序员可以一日无饭，却不能一日无git。是什么能让各路程序员如此着迷？今天，让我们走进git，看一看领略下这款传奇游戏的精彩。
虽然是一款面向程序员的游戏，但git的操作其实并不复杂。总的来说，这是一款有关同步与发展的游戏，游戏模式分为团队在线，个人在线，个人本地等多种，其中又以团队在线最受欢迎，我们今天的讲解就以团队在线为主。
在团队在线游戏中，参与者一方面需要贡献自己的成就与进展，另一方面又要同步团队中其他人的成果，整个团队的游戏成果以一个树形进行展现，树上每一条分叉称为一个“分支”。在游戏中，你可以提交成果来推进分支，也可以创建新的分支与他人分道扬镳，甚至可以通过合并分支来获取特性。在经过无数次的分裂合并的演变过后，游戏也会演变地千奇百怪，这也是该游戏的魅力所在。
在git游戏中，每个玩家都拥有3个区域可供操作，线上游戏中还会有一个远程仓库提供同步存储等操作。玩家手中的游戏区域分别为：工作区，暂存区和版本库。
工作区是玩家日常产出成果的区域，是玩家工作的地点，工作区的内容在git中没有记录，若玩家不进行添加提交，该区域的内容就不会被保存至git。
暂存区可以理解为工作区和版本库中间的一个缓冲，它存储的是玩家工作区目录的索引，用来保存玩家的工作进度。玩家可以使用add操作将工作区的内容添加进暂存区。
版本库是最终进行成果保存以及同步的地点，玩家可以使用commit操作将暂存区的内容提交至版本库，这一操作会推进你的本地分支，并在记录上增加你所做的一切。
最后，远程仓库是存储所有人进展的地方，人们可以通过push操作将自己的成果推送到远程仓库，也可以用pull拉取远程仓库的信息同步到本地。
在游戏中提供了多种技能供玩家使用，如用于同步的add，commit， fetch， push，pull；用于查询的status, log, reflog, diff, show；用于分支操作的branch， merge，remote， reset，checkout，rebase；以及我也不知道怎么分类的balabala。下面我们来详细讲解这些技能
（此处省略一万字）
讲解完基本操作，我们来了解一下游戏中常见的一些操作。需要注意的是，当你执行切换分支，同步分支等操作之前，最好确认你的工作区和暂存区是干净的
执行任何其他操作之前看一看工作区和暂存区的内容总是好的
git status
工作区不干净的时候执行一些操作比如切换分支、同步是十分危险的，如果你不想放弃你的修改，又不想提交他们，将他们储藏起来是一个不错的选择。
git stash #储藏未提交修改
其他操作 #爱干啥干啥
git stash pop #把修改应用到所在的分支上
注意：stash是一个栈结构可以保存你的未同步修改，但执行pop时它会将保存的修改放入你当前所在分支，而不是你压栈的分支（如果两个分支不同的话）。另外，因为这是一个栈结构，你pop出的永远是你最后压进去的那个修改（拿到指定修改看下一条）
上一个连招的缺陷是不能乱压乱恢复，想要恢复指定修改可以使用如下操作
git stash #储藏（可以有多个）
git stash list #查看所有储藏
git stash show -p stash@{0} #查看指定储藏
git stash apply stash@{0} #应用指定储藏
此套操作用于将工作目录内容提交至本地版本库
git status #看有啥需要提交
git add dir/file_name #添加到暂存区
git commit -m "xxx" #提交到版本库，xxx为提交描述（必须写）
将B分支的修改合并到A上，保证A的工作区和暂存区是干净的。
合并完成后可以理解为A和B在内容上是两个“相同”的分支
git checkout A #切换到A分支
git merge B #把B的修改合并到A上
注意：可能会有冲突，需要合并冲突。
merge可能有冲突，步骤：
解决冲突 #按git提示挨个打开冲突文件编辑
git add file_name #把修改添加进去（有几个填几个）
git commit #添加完提交给git
将B的修改在A上复现一次。rebase和merge不同，rebase相当于将B从和A分叉开始的所有修改都在A上重新提交一次，然后合并完成后B分支会被删除。
为了你的安全考虑，不要对已经在远程仓库的分支执行rebase
git checkout A #切换到A分支
git rebase B #将B分支的内容rebase到当前分支
（如果有冲突）
解决冲突 #修改冲突文件
git add #添加修改
git rebase --continue #继续rebase
注意：rebase的冲突解决是遇到一个冲突解决一个冲突，然后继续rebase。rebase会造成B分支的删除，不要将其用在远程操作中
用于同步远程分支到你的工作区。操作前保证本地目录是干净的
git fetch #拉取所有远程分支，保存到本地origin/xxx分支（xxx为远程分支名）
git merge origin/branch_name #将指定远程分支修改同步到本地
如果可以保证没有冲突，并且本地分支没有新修改，可以使用
git pull
脑抽写了一堆奇怪的代码？需求写到一半PM说这个需求又改了？没有理由劳资就是想回到以前的版本并且扔掉所有修改？
只要你的提交没push，这一切都不是问题。如果你已经push了你的修改，不要用reset，因为你的队友可能会弄死你
git log #查看commit记录，找到想回到的点
git reset --hard <commit> #尖括号内为指定commit的commit id
注意：以上操作可以让你回到过去的某一次commit的状态，操作方式是将版本库HEAD指针移到你指定的commit，这会造成版本历史中被回退的部分消失，在远程操作中这很反逻辑。
--hard选项会改变你的工作区、暂存区和版本库。如果你想保留你的代码，可以使用--mix选项，这样只会改变暂存区和版本库。还有一个--soft选项，加它只会改变你的版本库。
手贱reset了以后想恢复？
git reflog #查看修改历史，里面有你所有的操作（包括reset）
git reset --hard <commit> #“恢复”
不用想了，你没add和commit的肯定是回不来了，且行且珍惜吧
reset是一个很方便的回退版本的办法，但是不适用于远程。如果你的修改已经push了，这里有一个适用于远程的回退方法
git log #查看commit记录
git revert <commit> #撤销选中的更改
git push #如果你想的话
注意：和reset不同，revert是通过提交一次撤销来进行修改，他不会导致分支回退，而是使分支向前推进一步。和reset的另一个区别是，reset是回到指定的提交，而revert只是撤销指定的那一个提交，其他提交不受影响。
待续
标签：索引 远程分支 十分 面向 线上游戏 推荐 开始 checkout 修改
原文地址：https://www.cnblogs.com/Dumblidor/p/9310674.html
