【掌握版本控制：Git 入门与实践指南】操作仓库文件|分支管理

最新推荐文章于 2024-08-27 18:14:24 发布

慕斯( ˘▽˘)っ

最新推荐文章于 2024-08-27 18:14:24 发布

阅读量1.7k

点赞数 61

分类专栏：法器—GIT 文章标签： git linux 编辑器后端

本文链接：https://blog.csdn.net/weixin_64038246/article/details/136644206

版权

法器—GIT 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

🎬慕斯主页：修仙—别有洞天

♈️今日夜电波：泥中に咲く—ウォルピスカーター

0:34━━━━━━️💟──────── 4:46
🔄 ◀️ ⏸ ▶️ ☰

💗关注👍点赞🙌收藏您的每一次鼓励都是对我莫大的支持😍

已经 add ，并且也 commit，回退到上（一、二）版本

Git基本操作

查看修改操作

我们可以通过如下命令得知git下文件是否有被修改：

git status

该命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改，如下：

我们可以根据如下命令来查看差异：

git diff [file] //显⽰暂存区和⼯作区⽂件的
git diff HEAD -- [file] //查看版本库和⼯作区⽂件的

例子：

在这个diff中，--- 表示改动前，+++表为改动后，@@ -1 +1,2 @@表示了变化发生的位置。-1表示旧版本中的第一行，+1,2表示新版本中的第一行到第二行。

接着是具体的变化，-表示被删除的行，+表示被添加的行。在这个例子中，you can see me!是旧版本中的内容，而114514是新版本中新增的内容。

版本回退

我们可以使用以下的命令用于版本回退：

git reset [--soft | --mixed | --hard] [HEAD]

--soft：仅回退HEAD指针，不改变暂存区和工作区。
--mixed（默认模式）：回退HEAD指针，同时重置暂存区，但保留工作区。
--hard：回退HEAD指针，同时重置暂存区和工作区，丢弃所有更改。

HEAD 说明：

可直接写成commit id，表⽰指定退回的版本

HEAD 表⽰当前版本

HEAD^ 上⼀个版本

HEAD^^上上⼀个版本

以此类推...

可以使⽤〜数字表⽰：

HEAD~0表⽰当前版本

HEAD~1上⼀个版本

HEAD^2上上⼀个版本

以此类推...

如下示例：

如果我们回退错了，拿我们可以回退到之前提交的版本呢？

使用如下命令查看记录本地的每⼀次命令：

git reflog

再使用如下命令来回退到对应的版本，这里就体现到我们commit时做的“标记”的作用了：

git reset --hard [commit id]

工作区还没add，回退暂存区

通过如下命令可以让让⼯作区的⽂件回到最近⼀次 add 或 commit 时的状态：

git checkout -- [file]

如下：

已经add，没commit，回退版本库

git reset --mixed HEAD [file]

如下：

已经 add ，并且也 commit，回退到上（一、二）版本

 git reset --hard HEAD^//（^根据要回退版本数量来决定）

如下：

删除操作

如果只是删除工作区和暂存库中的内容，可以使用以下命令：

git rm [file]

如果想将版本库中也删除则再commit即可！

分支管理

如何创建分支？

如下命令为查看以及创建分支：

git branch //查看，带上-a可看全部
git branch 分支名//创建对应的分支

可以发现如果刚刚创建完分支，那么.git下会出现新的分支，并且 HEAD指向的是同一个修改。其中*表示为当前HEAD指向的分支。

如何证明指向的是同一个修改：

当我们新commit后，HEAD指向的分支跟着走：

如何切换分支？

如下命令可以切换：

 git checkout 分支名

在切换完成后，那么HEAD指向切换的分支，并且新commit会在该分支下：

如下为图解：

如何合并分支？

如下命令可以合并：

git merge 分支名

需要注意的是：我们要合并在哪个分支上，首先要交让HEAD指向那个分支！例如：如下我要将maz分支合并到master上：

图示如下：

如何删除分支？

如下命令删除分支：

git branch -d 分支名

如下图示：

需要注意的是：因为创建、合并和删除分⽀⾮常快，所以Git⿎励你使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在master分⽀上⼯作效果是⼀样的，但过程更安全。

合并冲突问题

我们可以使用如下命令一步完成创建并且切换分支的操作：

git checkout -b 分支名

在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题，比如同一段代码：在master分支下位 aaa，另外一个分支下位 bbb。此时在合并时可能就会出现合并冲突的问题。Git会⽤<<<<<<<，=======， >>>>>>>来标记出不同分⽀的冲突内容 。此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！

如：根据提示提交对应的文件：如：add再commit。大致的图示如下：

合并前：

合并后：

我们可以使用如下命令得到如上述图很像的分支情况:

git log --graph --pretty=oneline

分支管理策略

通常我们在合并分支的时候，如果没有特意的指定合并模式，Git会采⽤ Fast forward 模式 。大致的合并效果如下（可以看到分支的信息并没有显示出来，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息）：

上面我们提到的合并冲突是通过git log --graph --pretty=oneline指令很明显的看到与Fast forward 模式不同的效果，我们在删除了分支后如若可以在分⽀历史上就可以看出分⽀信息。我们可以通过以下的选项强制禁用Fast forward 模式：

git merge --no-ff -m "阿巴阿巴" 分支名

禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去！

如何通过分支处理bug？

假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有bug，需要解决 ,在Git中，每个bug都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？ 我们可以通过以下命令将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来：

git stash

然后我们可切换到master分支上，新建一个分支来修复该bug，修复完成后合并master再删除该分支，那么我们此时还有回到dev2继续开发，因此切换回dev2分支，然后我们可以通过以下命令查看之前的工作现场去哪里了：

git stash list

再通过以下命令恢复现场，并且把stash也删了：

 git stash pop

也可以通过以下命令恢复现场，但是恢复后stash内容并不会被删除，而是需要额外的命令进行删除：

git stash apply

删除stash：

git stash drop

但是我们在开发完成dev2分支的功能后并且提交后，发现我们之前修复的bug内容并没有在dev2上显示，大致示意：

因为master分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们在 dev2 中当然看不⻅修复bug的相关代码。我们最好不要直接merge到master上，这样其实是有⼀定⻛险的。解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并dev，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。 大致的示意图：