2.8.1Git项目管理

总目录：https://blog.csdn.net/qq_41106844/article/details/105553392

Python-后端 - 子目录：https://blog.csdn.net/qq_41106844/article/details/105553324

 

 

官方手册：https://git-scm.com/docs

参考：https://morvanzhou.github.io/tutorials/others/git/1-1-why/

为什么需要git

当你正在变成码农的路上，或者已经是码农的时候，就需要git了。

他会将同一个文件的不同历史版本变成一个文件。

下载路径：https://git-scm.com/downloads

一路默认参数下一步安装即可。

 

创建/修改版本库

 

创建版本库

首先找到 git bash，打开它。

 

 

然后添加用户标识，我们添加两个标识，分别是user.name和user.email

 

建立用户标识

 

查看用户标识

在git bash中，它遵循shell的命令。

我们新建一个文件夹用来当版本库。

 

建立版本库

我们可以看到他生成了一个.git的隐藏文件夹，我们看看他里面都是什么

 

git内容

这里面的数据不要随意修改。

 

添加文件管理

之后我们就要往版本库里面添加文件了

 

添加文件

我们直接在版本库内新建一个文件。

 

查看

但是查看发现，这个文件并没有被纳入版本库。

我们看到提示中让我们使用一个命令  git add。

 

 

提交改变

这样，这个文件才算被纳入版本库。

提交改变

这样，文件才算真正提交上去了。

 

提交改变

流程图：

 

 

 

 

记录修改

查看当前的log

并对cs.py作出修改。

 

 

 

这时查看状态，cs.py的状态变成了未纳入。

 

 

纳入版本库

 

 

提交，再次查看log

 

 

log从1个变成了2个。

如果我们想要查看一下刚才进行的修改是什么，可以通过git diff  前提是没有进行add操作将修改后的文件纳入版本库。

 

 

如果已经进行了add操作，那么不要着急，我们还有一个cached参数。

 

 

这样就OK了。

我么先别提交，我们在修改一下cs.py。之后使用一个新的参数查看一下。

 

第三次修改

 

三种不同的方法

 

回到从前

 

回到 add 之前

有时我们添加 add 了修改, 但是又后悔, 并想补充一些内容再 add. 这时, 我们有一种方式可以回到 add 之前. 

 

 

 

 

我们添加add后，查看状态是绿色的M，就是已添加（staged），使用reset，删除掉这次添加，就变成了红色的M，就是未添加（unstaged）。

 

 回到 commit 之前

每个 commit 都有自己的 id 数字号, HEAD 是一个指针, 指引当前的状态是在哪个 commit. 最近的一次 commit 在最右边, 我们如果要回到过去, 就是让 HEAD 回到过去并 reset 此时的 HEAD 到过去的位置.

不管我们做了什么add操作，这一步直接回到上一个commit。

 

 

让我们回到change1，同样也可以使用id号返回。

 

 

查看log。

 

 

那么怎么回到change2呢。

 

 

首先查看最近我们做了哪些操作，然后找到  moving to HEAD 的id号，回到这个id。

 

改写文件 

我们首先拷贝一个cs1.py，然后追加到change2中。

 

 

我们先看一下我们的log。

 

 

我们指定cs.py回到 3ad86f5 的这个log。

 

 

之后将cs.py提交上去。

 

 

 

分支管理

 

创建分支

使用branch创建一个分支，使用checkout来切换分支。

 

 

使用checkout -b 参数可以直接创建+切换。

 

 

dev01 分支中的 cs.py 和 cs1.py 和 master 中的文件是一模一样的. 因为当前的指针 HEAD 在 dev01 分支上, 所以现在对文件夹中的文件进行修改将不会影响到 master 分支.

我们在 cs.py 上加入一些东西, 然后再 commit（-am代表add+commit）

 

 

将 dev01 的修改推送到 master

我们先切换回master，之后使用merge合并他们。

 

 

之后就可以我们合并了他。

 

 

要注意的是, 如果直接 git merge dev, git 会采用默认的 Fast forward 格式进行 merge, 这样 merge 的这次操作不会有 commit 信息. log 中也不会有分支的图案. 我们可以采取 --no-ff 这种方式保留 merge 的 commit 信息.

 

 

分支冲突

merge（合并分支冲突）

情况是这样, 想象不仅有人在做开发版 dev 的更新, 还有人在修改 master 中的一些 bug. 当我们再 merge dev 的时候, 冲突就来了. 因为 git 不知道应该怎么处理 merge 时, 在 master 和 dev 的不同修改.

当创建了一个分支后, 我们同时对两个分支都进行了修改：

master 中的 cs.py 加上 # edited in master.

dev 中的 cs.py 加上 # edited in dev.

 

 

 

 

master的log

 

dev的log

当我们想要 merge dev 到 master 的时候，git 发现的我们的 cs.py 在 master 和 dev 上的版本是不同的, 所以提示 merge 有冲突. 具体的冲突, git 已经帮我们标记出来, 我们打开 cs.py 就能看到:

 

 

我们随便修改一下cs.py，让里面的内容在当前HEAD统一。

 

 

 

然后进行提交

 

 

冲突就会解决掉：

 

 

 

 

rebase（重新划分分支冲突）

假设共享的分支是branch B，我而在branch A上工作，一天有我发现branch B已经有一些小更新，我也想试试我的程序和这些小更新兼不兼容，我也我想合并，就这时可以用rebase来补充我的分支branch B的内容。补充完以后，和后面那张图的merge不同，我还是继续在C3上工作，不过此时C3的本质却不一样了，因为吸收了那些小更新。我们所以用C3'来代替。

 

 

 

 

 

 

 

 

 

 

 

可以抛光rebase改变了C3的属性，C3已经不是从C1衍生而来的了。这一点和merge不一样。merge在合并的时候创造了一个新的C5 commit。这一点不同，使得在共享分支中使用rebase变得危险。如果是共享分支的历史被改写。别人之前共享内容的commit就被你的rebase修改掉了。

 

 

 

只能在你自己的分支中使用rebase，而别人共享的部分是不能用 。如果你不小心弄错了了。没事，我们还能用reflog恢复原来的样子。为了验证在共享分支上使用rebase的危险性，我们在下面的示例中也验证一下。

 

我们先将master和dev中的cs1.py修改为不同内容。

然后进行合并：

 

 

 

 

这时HEAD并没有指向master或者dev，甚至停在了rebase模式上

然后手动合并，再次rebase，这时必须使用  --continue 参数。查看log。

 

 

这个例子也说明了使用rebase要万分小心，千万不要在共享的branch中rebase，不然就像上面那样，现在master的历史已经被rebase改变了。其中master别人提交的change就被你无情地修改掉了，所以千万不要在共享分支中使用rebase。

 

临时修改

假如我们正在进行任务a，突然有一个紧急任务b介入，需要先停下手里的工作来完成任务b，但是不能将任务a和任务b同时commit，所以就有了暂存，也就是临时修改。

我们来dev这个分支来做。

 

 

我们修改了一下cs.py文件，然后先不add，用stash来暂存他。之后查看他的状态，发现是另外一种情况。

然后我们来做任务b

介入其他任务

创建并进入taskb

 

 

完成taskb任务并且提交。

 

 

回到master进行合并，如果有冲突则先修改文件进行合并。

 

 

查看log

 

 

 

恢复工作

先切换回dev分支，之后查看一下stash的缓存。

 

 

通过pop提取他，继续工作。