1. 修改文件
Git比其他的版本管理器设计得更加优秀，因为。
修改一个文件，不管你是添加一行，或者删除一行，还是添加了又删除了，甚至你创建了一个新文件，只要和源文件有所不同的，这些都算是一个修改。
现在我们来对ReadMe文件做一下修改：
修改前：
修改后：
目前仓库的ReadMe和工作区的ReadMe是不同的。使用 命令可以查看文件是否被修改。
很清楚，红色的字体就可以看出来，文件是被修改了的。工作区的ReadMe文件被修改了，还没有进行add和commit操作。
目前我们只看见了文件被修改了，但是不知道具体文件的哪一个位置被修改了，用一个命令可以查看具体修改内容的位置。
:显示工作区和暂存区文件的差异。
:显示暂存区和版本库文件的差异。
git add 之后，就没有看到上面 no changes added to commit (use “git add”
and/or “git commit -a”) 的消息了。接下来让我们继续 git commit 即可：
这时所有的修改文件已经被提交到了版本库了。
2. 版本回退
如果有一天你发现你的工作出现了问题，需要回退到某个历史的版本重新开始，这时你就需要版本回退的功能了。
版本回退功能：。这里的 “回退” 指的是文件的内容进行回退。
命令语法格式为：
- –soft: 回退版本库，而工作区和暂存区不变。
- –mixed：回退暂存区和版本库，而工作区不变，注意这是默认选项。
- –hard：回退暂存区、版本库和工作区。
- ：
◦ 可以直接写成 commit id，表示回退到指定的版本。
◦ HEAD 表示当前版本。
◦ HEAD^ 表示上一个版本。
◦ HEAD^^ 表示上上一个版本。
◦ 以此类推……
- 也可以使用~数字来表示：
◦ HEAD~0 表⽰当前版本
◦ HEAD~1 上⼀个版本
◦ HEAD~2 上上⼀个版本
◦ 以此类推……
为了方便测试回退功能，我们写3个版本的ReadMe，都进行commit操作。
版本1：
版本2：
版本3：
最后提交的是版本3，某些原因，我们需要回退到版本2，重新开始工作，由于需要将工作区的ReadMe文件回退了，所以需要
选项。
这里的回退我们使用 来做，于是需要 ，来查看最近几次的 commit id。
如我们所料，当前的ReadMe文件已经回退到了版本2，当前我们使用git log来查看一下提交日志，可以发现HEAD指向了版本2。
到这里我们的回退工作就算是完成了，但是我后悔了，我想再回到版本3怎么办？我们可以继续使用git reset，但是我们目前git log打印日志，没法知道版本3的commit id。
Git提供了一个命令来补救一下，该命令用来记录本地的每一次命令。
注意这里的黄色的内容是commit id的部分，通过这个id可以进行文件操作。
值得注意的是，在实际的开发中，由于长时间的开发，导致commit id早就找不到了，某一天你先回退到version3版本，那如何操作呢？貌似是不可能了！！！
值得说的是，Git 的版本回退速度非常快，因为 Git 在内部有个指向当前分支（此处是master）的HEAD 指针， 文件里保存当前 master 分支的最新 commit id 。当我们在回退版本的时候，Git 仅仅是给 refs/heads/master 中存储⼀个特定的commit id，可以简单理解成如下⽰意图：
3. 撤销修改
3.1 情况一：对于工作区的代码，还没有add
当你对工作区中的文件写了几天的代码，但是你一直没有进行add操作，这时你觉得这几天写的代码不行，你需要重新写，因为你写了很多代码了，你也记不住写了哪些代码，当然也不可能一行一行的在源文件中去删除。
Git给我们提供了好的方式 – ,让文件回到最近一次add或commit的状态。该命令中的–是很重要的，千万不能少，这是啥意思呢？后面说。
示例：
3.2 情况二：已经add，但没有commit
对于此状态下，我们可以使用git reset中的–mixed选项，回退暂存区，而工作区不变。
在工作区中的文件新增了三行内容，然后进行add操作。我们的目的是撤销add操作，使得暂存区回到上一次操作。
可以发现，暂存区是干净的，而工作区有修改。
你可以再次使用 git checkout – ReadMe 命令，让工作区的文件回到上一次add的状态。
3.3 情况三：已经add，并且已经commit了
这个简单，就是我们之前提到的 回退到上一个版本。
不过！这是建立在你还没有将本地版本库提交到远程版本库（后续会说到），如果已经提交到了本地版本库，那么就无力回天了。
4. 删除文件
在git中删除文件也是一种修改操作。
在工作区使用rm可以删除文件吗？
此时，git status会告诉你，哪些文件被删除了，但是这里的只是删除了工作区中的文件，版本库中的文件可没有删除掉。
走到这里：
①不小心删错了。
②确实要从版本库中删除该文件。
对于第一种情况，删错了， 就可以恢复了。
对于第二种情况，显示是没有删除干净的，git中有一个命令提供给我们删除工作区和版本库中的文件：
并且执行commit：
1. 理解分支
在版本回退里，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分支。截止到目前，只有⼀条时间线，在Git，这个分支叫主分支，即 master 分支。
再来理解⼀下HEAD，HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分支。
每次提交。master分支都会向前移动一步，随着你提交的越来越多，master分支也越来越长，但是HEAD是一直指向的master分支的。所以当前分支一直是master分支。
2. 创建分支
Git支持我们创建和查看分支。
：查看当前本地的所有分支。
:创建dev的分支。
很明显，当前有两个分支，并且两个分支都指向的同一个修改。但是HEAD还是执行master分支的。
下面的图就能清晰的看出它们的关系：
3. 切换分支
当我们创建出了dev分支，需要转换到dev分支上进行开发，如何做到呢？
可以切换分支。还有一个命令可以直接创建并切换分支，一步到位：
切换到了dev分支了之后，我们就可以在该分支下进行工作了。
现在，dev分支工作完成了，我们切换到master分支上去。
切回到master分支上了之后，发现ReadMe上新增的内容不见了。赶紧切回到dev看看。
在dev分支上内容是还在的，为什么会出现这种情况呢？我们来看看dev和master的指向就知道了
可以看到它们两个的指向是不一样的，到这里就理解了，我们是在dev分支上提交的，但是master分支上此刻的提交点并没有改变。
我们就可以得到下面的图：
当切换到master分支上的时候，HEAD执行master，当然就看不到dev上的了。
4. 合并分支
为了解决上述问题，master上也能里面看到新的提交，我们就需要将dev分支合并到master分支上去。
合并的时候切，换到master分支下，使用命令：
这时，在master分支下，也能看到新的提交了。
示意图就变成了这样：
Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能 Fast-forward，我们后面会讲其他⽅式的合并。
5. 删除分支
当前dev分支合并完成后，对我们来说就没啥用了，于是我们就可以删除该分支了，注意，当前处于dev分支下，是不可以删除dev分支的。
删除分支命令：
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是⼀样的，但过程更安全。
6. 合并冲突
在合并分支的时候，并不是我们想合并就能合并成功的，有一种情况，会有合并冲突出现，这时就需要我们自己手动来解决该问题。
举个例子：
- 创建一个新的分支dev1并切换过去：,然后再dev1分支上，将ReadMe文件进行修改，然后add和commit操作。
- 再切换到master分支，查看ReadMe文件，看到还是aaa内容，之前说过了，这也很正常。
- 但是现在在master分支上我们也进行修改ReadMe文件，并且进行add和commit操作。
此时的结构图如示：
- 最后一步，将dev1分支合并到master分支上。
执行git merge dev1合并命令的时候，出现了很明显的字样，合并冲突。为什么会出现这种情况呢？
因为两个分支修改了同一个文件，git不知道要管理哪个了。所以这时候，就需要我们手动解决冲突。
解决冲突：
当我们查看ReadMe文件，会看到这些内容：
多了三行我们看不懂的内容，<<<<<<< HEAD、=======、>>>>>>> dev1。
解释：
①<<<<<<< HEAD和=======之间的内容是master分支修改的内容。
②=======和>>>>>>> dev1之间的内容是dev1分支修改的内容。
③其他的内容就是没有修改过的。
为了解决冲突，我们需要手动的删除多了的三行内容，选择你要留下来的内容。你可以将ccc和bbb内容都留下来，或者留一个等。
这里我选择将两个内容都留下来,修改文件内容后，最后还要进行add和commit操作，这样我们就完成了解决合并冲突了。
此时的状态就变成了：
其实git给我们提供了带参数的git log命令可以查看分支合并情况。
这里使用
最后记得将dev1分支给删除掉。
7. 分支管理策略
通常合并分支的时候，如果可能，Git会采用Fast forward模式，我们第一次合并分支的时候，就是该模式，会出现下面的情况。
在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。
删除了dev分支后，就会出现下面的情况：
dev分支提交的信息就会消失，我们就看不出来最新的提交是master自己提交的，还是其他分支合并提交的。
在我们上述解决合并冲突的例子中看出该模式就不是Fast forward模式了。
即使你删除了dev分支，依然可以看到master的最新一次提交是其他分支合并得到的。
接下来我们可以实操一下，很简单，我们先创建并切换到dev2分支，在dev2分支上修改ReadMe文件，并进行add和commit操作，然后再切换到master分支上，将dev2分支合并到master上。只不过这里的合并命令和之前的不一样，需要添加选项 ,完整的命令：
禁用 Fast forward 模式后，会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。
合并之后应当变成这样：
即使你删除了dev2分支后，依然知道这是分支合并提交的。
7.1 分支策略
在实际开发中，master分支是非常稳定的，仅仅用来发布新的版本，不能在上面进行开发。
我们开发都是在其他分支上进行开发，做完活之后，测试也通过了之后，再将这些分支合并到主分支上去。
所以，团队合作的分支就像这样：
8. bug分支
假如现在我们正在dev2分支上进行开发，突然master分支上出现了bug，需要解决。在Git中，每一个bug都可以单独开一个临时分支出来进行修复bug，修复后，合并该分支到master分支上去，然后将该临时分支删除掉，然后继续dev2的工作。
比如，当前dev2正在进行开发到一半了，还无法进行提交。
此时出现了master分支上出现了bug，我们需要切换到master分支上去，创建出一个临时分支去修复bug。
但是此时dev2分支开发的内容还没有开发完，因为还没有提交，所以master分支上也是可以看到dev2上新开发的内容，但是我们是不需要master分支看到这个内容，所以我们需要将dev2新开发的内容，临时保存下来，当bug分支修复后，再恢复出来。
Git提供了 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。
使用了git stash命令后，工作区就是干净的了，这时我们就可以放心切换到master分支上，创建临时分支修改bug了。
修复bug：
修复完成后，切换到master分支，并完成合并，删除fix_bug分支。
至此，修复bug的任务已经完成了，我们切换到dev2分支，继续完成我们的任务。
工作区是干净的，之前的dev2的工作现场存到哪里去了？使用 命令查看，可以看到新增了一个stash文件。
该stash文件就是存放的dev2工作的内容。为了完成dev2的工作，我们需要将stash中的内容恢复出来。
恢复命令：，恢复内容的同时，也会将stash文件给删除了。
你也可以使用 恢复，但是恢复后，stash内容并不删除，你需要使用 删除。
我们可以看到修复bug的内容，并没有在dev2分支上显示，这也很正常，此时的状态图：
这个时候我们需要将dev2分支合并到master分支上去，但是这样又有一个问题，dev2和master的最新的提交是都修改了文件的，所以会有合并冲突，所以我们需要手动的解决冲突，但是，冲突的代码可能不止一行，可能成百上千行，我们手动的去解决冲突，可能会破坏master分支上ReadMe文件中的原本内容。
解决问题的好的建议是。最好在自己的分支上合并master分支，再让master分支去合并dev2分支。就像下面两个图所示：
这里具体例子就不举例了。
显示的结果如示：
9. 删除临时分支
实际开发中，添加一个新的功能时，最好新建一个新的分支，我们把这种分支叫做 feature 分支。
可是，当我们在feature分支上开发到一半了，产品经理告诉我们，该功能取消了，那么你就需要删除该分支。
使用传统的 删除分支是不行的。
这时突然该功能取消了，你需要切换到master分支上，然后删除dev3分支。
但是这样删除是不行的。提醒我们使用 git branch -D dev3。
10. 小结
分支在实际中有什么用呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能干活了。如果等代码全部写完再⼀次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了⼀个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分支上，这样，既安全，又不影响别人工作。并且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
到此这篇git用法详解（git怎么用的）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/bcyy/18512.html