Git Learning
(Ubuntu 环境下)
1. 在进行工作区修改文件撤回时：
会出现3种情况
| 工作区 | 暂存区 | 版本库 | 解决方式 |
|---|---|---|---|
| 有需要修改的代码 | 无 | 无 | 1.手动撤销–不推荐 2.使用git checkout – 文件名 |
| 有需要修改的代码 | 有需要修改的代码 | 无 | git reset HEAD 文件名 |
| 有需要修改的代码 | 有需要修改的代码 | 有需要修改的代码 | 前提条件: commit 后面没有push git reset |
注意：撤销的目的是为了防止不好的代码被push到远程仓库中。
2. 如何删除工作区的文件
方法一：直接在文件工作区删除文件
方法二：使用git rm命令
git__28">3. git 分支管理
- 举个例子：🌈🌈🌈
😄
在一个玄幻的武侠世界中，一个名门望族之女，即将出嫁，为了选取夫婿，举行了一场比武大会。 此时，你和你的对手都跃跃欲试。
😄 在刚开始的时候你和你的对手旗鼓相当，不出所料的选择了同一个计划，但是你用之前的影分身多学了一套剑法
你的实际准备
你的对手的实际准备
- 这就是一个简单的分支
git__64">3.1 git 的分支管理的内容
- 通过master指针找到最新的提交
- 再通过
parent指针找到以往的提交
- 同时我们还可以在主分支中创建分支
3.2 创建分支
- head 不只可以指向master(主分支),还可以指向其他分支
- 被指向的分支就是工作区的分支
git branch 分支名
😄 如：git branch dev🌈🌈🌈
现在我们就创建了一个dev分支
因为这个分支是在我们最新的版本情况下创建的，所以他也指向我们最新的提交
- 现在我们想要切换分支
git checkout 分支名
在切换前，我们的分支指向主分支：
切换后：
- 现在我们再次更改
readme.txt文件
- 提交后，我们再次切换回主分支
- 这时我们会惊奇的发现redme.txt文件的修改都不见了！！
- 在切换回来之后又会发现，内容又回来了。
通过证明，我们得到结论：
- 在dev 上创建commit，并切换回主分支，不会影响到主分支的commit。
此时的两个分支就是互不影响的，接下来我们可以对他们进行合并操作。
3.3 合并分支
现在我们想要将dev分支上的操作合并到master分支上， 首先就要切换到master上
- 合并分支的命令是
git merge 分支名
现在我们将dev分支合并到master分支上：
git checkout master
git merge dev
在进行合并操作时，我们可以看到fast-foreward的标识， 现在说明我们的master分快速地指向了dev commit
3.4 删除分支
上面我们进行合并操作之后，dev分支的用处就不大了，为了节省资源， 现在删除dev分支
-
删除分支的命令是
git branch -d 分支名 -
进行分支删除时，必须切换为主分支，否则会报错。
-
在实际的工程中我们鼓励使用分支，因为这样的操作使得我们的代码更加安全，也更加方便管理。
3.5 分支合并冲突
-
分支出现的情况
在创建的分支dev和master分支都对readme.txt文件进行操作，在合并时，会出现合并冲突。
- 现在我们来模拟这个过程并解决这个问题：
创建一个分支 & 切换到这个分支上
git checkout -b dev
完成下面的步骤 🌈🌈🌈
- 现在我们再readme.txt文件中添加一行内容：
- 我们再次提交到dev1分支上
- 切换到master分支上，也添加上一行内容
- 再次提交到master分支上
现在直接使用git merge dev1命令进行合并，会出现合并冲突
现在readme.txt文件内容如下：
-
现在的冲突就需要们认为解决，我们可以选择保留其中一个分支的修改，或者是手动合并。
拓展： 其实log命令也可以进行可视化的展示
git log --graph --oneline --all git log --graph --abbrev-commit
3.6 分支管理-合并模式
- Fast-forward模式
快速地合并，提交，但在可视化中无法分辨出是哪个分支的提交。
- –no-ff
为了解决这个问题，我们可以使用--no-ff参数，这样就会创建一个新的提交，并将两个分支的提交都指向这个新的提交。
git merge --no-ff -m "合并分支" dev1
-m的出现是为了是master分支指向新的提交。
4. 分支策略
4.1 master 分支具有稳定性
✈️✈️✈️🌈🌈🌈
在日常的开发中，开发人员提交的代码，还没有进过测试（不稳定存在bug）, 所以 master 分支是最稳定的分支。
4.2 bug 分支
当开发人员发现了一个 bug 时，他们会创建一个 bug 分支，然后修复这个 bug。
- 假设我们现在遇到了这样的情况
此时我们在dev2进行开发时，突然发现了一个主分支上的Bug,现在我们怎么办？
在遇到这样的情时，我们一般会在创建一个分支来修复，主分支上的bug.
现在主分支上的问题就解决了，但是，在进行dev2开发时，master分支上已经有BUG了
如果此时我们直接将新开的功能直接合并到master分支就会出现新的问题。
所以此时我们就可以将master分支上的内容合并到dev2分支上，
将所有的问题解决了，然后再将dev2分支合并到master分支上
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!!
。。。开发了这么久的项目说不要就不要么！？
没得办法，现在就只能将自己的心血删除掉了。
现在你的分支上已经有很多东西了，一般的方式无法将其直接删除，这时我们就需要用到新的命令：
git branch -D 分支名
5.远程操作
仓库的建立、克隆、推送、拉取、删除等操作都需要远程操作，下面介绍一下远程操作的命令。
mindmap
root(远程操作)
((拉取))
((克隆))
😄 除此之外我们需要再gitee云平台上创建自己的仓库，搭建自己的码云。
5.1 创建自己的仓库
由于github在国内的访问受限，我们就更倾向于使用国内的云平台来托管我们的代码，因此，gitee就成为了我们得首要选择。
首先我们来到gitee平台:
如果还没有注册，就需要注册一个账号。
进入之后，现阶段就只需要填写这些信息，后面如果有需要，再反过来填写相应的信息。
在个人的主页下就可以查看自己创建的仓库了。
5.2 克隆远程仓库(clone)
创建完远程仓库后，我们就需要在文件目录下克隆我们创建的仓库，这样我们才能够将该文件路径下的文件推送到这个仓库之中。
在这里我就只讲最简单的这种方式（HTTPS方式），如果有需要就可以参考一下其他的文章。
这个操作十分的简单，我们首先需要拿到我们需要的网址：
首先进入我们得gitee码云平台：
拿到网址后，我们就只需要在命令行窗口输入这一行命令就可以了：
git clone `你的网址`
之后这个文件路径下就会出现一个和你的仓库同名的仓库。
接下来我们在这个文件夹中的文件内容修改操作，都可以通过命令推送到仓库。
好了，我们今天的gitee学习就到这里，我们下期再见，拜！！
🌈🌈😄
