git 学习（基于Ubuntu和gitee）

Git Learning

(Ubuntu 环境下)

1. 在进行工作区修改文件撤回时：

会出现3种情况

工作区	暂存区	版本库	解决方式
有需要修改的代码	无	无	1.手动撤销--不推荐 2.使用git checkout -- 文件名
有需要修改的代码	有需要修改的代码	无	git reset HEAD 文件名
有需要修改的代码	有需要修改的代码	有需要修改的代码	前提条件: commit 后面没有push git reset

注意：撤销的目的是为了防止不好的代码被push到远程仓库中。

2. 如何删除工作区的文件

方法一：直接在文件工作区删除文件

现在文件工作区删除文件
git add 提交变化到暂存区
git commit -m "删除文件" 提交到版本库

方法二：使用git rm命令

git rm 文件名(在工作区和暂存区都将文件删除)
git commit -m "删除文件" 提交到版本库

3. git 分支管理

举个例子：🌈🌈🌈
😄

在一个玄幻的武侠世界中，一个名门望族之女，即将出嫁，为了选取夫婿，举行了一场比武大会。此时，你和你的对手都跃跃欲试。
50% 50% 武侠世界比武大会你的水平你的对手

😄 在刚开始的时候你和你的对手旗鼓相当，不出所料的选择了同一个计划，但是你用之前的影分身多学了一套剑法

你的实际准备
分身合体你降龙十八掌参加比武大会辟邪剑法

你的对手的实际准备
你的对手降龙十八掌参加比武大会

这就是一个简单的分支

3.1 git 的分支管理的内容

提交时间主线主分支 1 2 3 4 5 最新一次的提交id HEAD master

通过master指针找到最新的提交
再通过parent指针找到以往的提交

同时我们还可以在主分支中创建分支
提交时间主线分支合并主分支 1 2 3 4 5 最新一次的提交id 分支1

3.2 创建分支

head 不只可以指向master(主分支),还可以指向其他分支
被指向的分支就是工作区的分支

git branch 分支名

😄 如：git branch dev🌈🌈🌈

现在我们就创建了一个dev分支

因为这个分支是在我们最新的版本情况下创建的，所以他也指向我们最新的提交
提交时间主线新建分支主分支 1 2 最新一次的提交id dev

现在我们想要切换分支
git checkout 分支名

在切换前，我们的分支指向主分支：

切换后：

现在我们再次更改 readme.txt文件

提交后，我们再次切换回主分支

这时我们会惊奇的发现redme.txt文件的修改都不见了！！
在切换回来之后又会发现，内容又回来了。

通过证明，我们得到结论：

在dev 上创建commit，并切换回主分支，不会影响到主分支的commit。

提交时间主线新建分支主分支 1 2 最新一次的提交id dev dev commit

此时的两个分支就是互不影响的，接下来我们可以对他们进行合并操作。

3.3 合并分支

现在我们想要将dev分支上的操作合并到master分支上，首先就要切换到master上

合并分支的命令是 git merge 分支名

现在我们将dev分支合并到master分支上：

bash 复制代码

git checkout master
git merge dev

在进行合并操作时，我们可以看到fast-foreward的标识，现在说明我们的master分快速地指向了dev commit

3.4 删除分支

上面我们进行合并操作之后，dev分支的用处就不大了，为了节省资源，现在删除dev分支

删除分支的命令是 git branch -d 分支名
进行分支删除时，必须切换为主分支，否则会报错。
在实际的工程中我们鼓励使用分支，因为这样的操作使得我们的代码更加安全，也更加方便管理。

3.5 分支合并冲突

分支出现的情况

在创建的分支dev和master分支都对readme.txt文件进行操作，在合并时，会出现合并冲突。

修改readme.txt 修改readme.txt HEAD master 最新一次的提交id master commit dev dev commit 合并冲突

现在我们来模拟这个过程并解决这个问题：

创建一个分支 & 切换到这个分支上

bash 复制代码

git checkout -b dev

完成下面的步骤 🌈🌈🌈

现在我们再readme.txt文件中添加一行内容：
我们再次提交到dev1分支上
切换到master分支上，也添加上一行内容
再次提交到master分支上

现在直接使用git merge dev1命令进行合并，会出现合并冲突

现在readme.txt文件内容如下：

现在的冲突就需要们认为解决，我们可以选择保留其中一个分支的修改，或者是手动合并。

拓展：其实log命令也可以进行可视化的展示
bash 复制代码
```
git log --graph --oneline --all
git log --graph --abbrev-commit
```

3.6 分支管理-合并模式

Fast-forward模式
快速地合并，提交，但在可视化中无法分辨出是哪个分支的提交。

--no-ff
为了解决这个问题，我们可以使用--no-ff参数，这样就会创建一个新的提交，并将两个分支的提交都指向这个新的提交。

bash 复制代码

git merge --no-ff -m "合并分支" dev1

-m的出现是为了是master分支指向新的提交。

4. 分支策略

4.1 master 分支具有稳定性

✈️✈️✈️🌈🌈🌈

在日常的开发中，开发人员提交的代码，还没有进过测试（不稳定存在bug）, 所以 master 分支是最稳定的分支。
张三基于2开发合并李四基于3开发合并 1 2 3 4 f1 f2 5

4.2 bug 分支

当开发人员发现了一个 bug 时，他们会创建一个 bug 分支，然后修复这个 bug。

假设我们现在遇到了这样的情况

测试出现Bug 1 2 Bug head dev2

此时我们在dev2进行开发时，突然发现了一个主分支上的Bug,现在我们怎么办？

在遇到这样的情时，我们一般会在创建一个分支来修复，主分支上的bug.
测试出现Bug 正在进行功能开发修复Bug 合并 1 2 Bug head dev2 fixBug 3

现在主分支上的问题就解决了，但是，在进行dev2开发时，master分支上已经有BUG了

如果此时我们直接将新开的功能直接合并到master分支就会出现新的问题。

所以此时我们就可以将master分支上的内容合并到dev2分支上，
将所有的问题解决了，然后再将dev2分支合并到master分支上
测试出现Bug 工作区内容指向正在进行功能开发修复Bug 合并合并修复问题合并到master 1 2 Bug head dev2 fixBug 3 f2 4

4.3 强制删除分支

zenuml title Conversation One @Actor manager @Actor me manager->me: Hi zdl. me->manager: How are you, is there any problem? manager->me: There we got a new request from boss to develop a new function . me->manager: Ok, I will create a new branch for this function.

zenuml title Conversation Two @Actor manager @Actor me manager->me: Hi zdl. me->manager: Hi, I'm still working on the new function, please wait for a second. manager->me: Ok, but I've got a breaking news to tell you manager->me:that the boss has changed his mind to cancel the new function. me->manager: Ok..., wait, what!!

。。。开发了这么久的项目说不要就不要么！？

没得办法，现在就只能将自己的心血删除掉了。
dev 1 2 new f

现在你的分支上已经有很多东西了，一般的方式无法将其直接删除，这时我们就需要用到新的命令：

bash 复制代码