git分支回滚合并变基等_合并回滚

git分支回滚合并变基等

上传项目

创建本地库:

创建远程仓库:

push时填写远程库地址

最终:

会默认上传忽略文件避免冲突

.gitignore文件

springBoot

vue

关于回滚

如上所说有些同学可能误删了.gitignore. 导致add的时候把.mvn之类的东西添加进去了 .如何处理呢 可以回滚

git的版本回滚其实就是回滚不同的分区，所以在聊git回滚之前我们有必要简单了解一下git的分区。git在本地有三大分区：工作区、暂存区、版本库

**工作区：**正在编写，还未add的部分，红色。

**暂存区：**add后的代码，绿色。

**版本库：**commit后的代码，灰色

在IDEA中，在loacl changes中可以看到在工作区中和暂存区中的内容：

• IDEA中显示的文件颜色
  • 红色：还没交给Git管理
  • 绿色：Git已管理，还未提交(从未)
  • 蓝色：作过修改，还未提交(之前修改过)
  • 灰色：文件删除，还未提交

版本库中的内容可以从log中看出来，log中可以看到commit test这条提交的分支是本地的main分支，如果是已经同步到远端的提交分支会显示为origin/main：

未commit，进行回滚

已经add到暂存区，但是未commit到本地版本库的改动有两种：

• 新增的文件
• 修改的文件

新增的文件直接删除即可，如果是修改的文件，使用roll back来回滚。在local change里面，选择想要rollback的文件即可：

在idea中，如果想要查看在git版本控制系统下修改的本地文件，发现在idea下方的窗格并没有，只有log和console两个模块。此时需要通过一下操作来查看本地修改文件

解决步骤：File ==》Settings ==》Version Control ==》Commit ==》将Commit中的【Use non-modal commit interface】前的对勾去掉，则可以在Git模块显示Local Changes

commit未push，进行回滚

commit到本地版本库并且还未push的代码，可以在log里右击单次提交进行undo commit：

需要注意的是undo commit只能从最后一次commit开始回滚，undo commit后会要求选择一个变更列表来存放回滚后的内容，可以自己新建一个，比如此处的commit test，也可以在下拉框里选择一个已经存在的，如果是自己新建的变更列表，勾选了set active选项，后续的变动也会存放到该变更列表中：

然后你可以参考已添加暂存区未commit状态 可以回滚 右键rouback 回归到未add到暂存区的状态

这个你可以删了. 如果开始没有勾选set active 他就会提示你直接删了

文件回到未add暂存区状态

revert (撤销/撤回/反提交)

比如 我们 版本有t1 t2 t3 如果git revert t1 , 那就只会撤销t1的提交. t2,t3保持不变,导致冲突

而reset,相当于整个回到t1那会儿的状态

revert仅仅是撤销指定commit的修改，并不影响后续的commit，但所撤销的commit被后续的commit修改了同一地方则会产生冲突；

revert执行后因为不会清除记录，并且会产生新纪录，所以文件不会丢失，你可以多次执行revert恢复到某次改变之前的状态；

而revert的HEAD则一直是向前的

reset

有时候我们需要直接将本地的代码回滚到版本库的某一个版本，这时候可以使用reset来进行回滚。reset有几种模式：

soft，将版本回滚，工作区不动，暂存区=原来的+回滚后和回滚前的版本差异。

mixed，将版本回滚，回滚到了所有 git add 和 git commit 的命令执行之前。暂存区变为空，变更全部到了工作区。(默认是这个)

hard，将版本回滚，将所有工作区和暂存区的文件修改全部清空，是真正的覆盖，不能找回了。

keep，将版本回滚，将所有commit的内容丢弃掉，未commit的内容保留

以上两者最终希望影响远程库,都需要 push, 但是如果远程库是错误版本,本地库是错误版本,那就需要强制推送

git push -f
1

总结：

reset是彻底回退到指定的commit版本，该commit后的所有commit都将被清除，包括提交历史记录；
revert仅仅是撤销指定commit的修改，并不影响后续的commit，但所撤销的commit被后续的commit修改了同一地方则会产生冲突；
reset执行后不会产生记录，revert执行后会产生记录；
reset执行后无法再次恢复，revert执行后因为不会清除记录，并且会产生新纪录，所以文件不会丢失，你可以多次执行revert恢复到某次改变之前的状态；
reset执行后HEAD会后移，而revert的HEAD则一直是向前的

关于分支

重点: 做任何操作都需要把当前自己工作区代码提交push,避免代码丢失,假如代码丢失不要慌,还可以使用idea的localHistory.

创建分支:

整个代码库中一共有五种分支。

Master 分支。也就是主干分支，用作发布环境，上面的每一次提交都是可以发布的。

Feature 分支。也就是功能分支，用于开发功能，其对应的是开发环境。

Developer 分支。是开发分支，一旦功能开发完成，就向 Developer 分支合并，合并完成后，删除功能分支。这个分支对应的是集成测试环境。

Release 分支。当 Developer 分支测试达到可以发布状态时，开出一个 Release 分支来，然后做发布前的准备工作。这个分支对应的是预发环境。之所以需

要这个 Release 分支，是我们的开发可以继续向前，不会因为要发布而被 block 住而不能提交。

一旦 Release 分支上的代码达到可以上线的状态，那么需要把 Release 分支向 Master 分支和

Developer 分支同时合并，以保证代码的一致性。然后再把 Release 分支删除掉。

Hotfix 分支。是用于处理生产线上代码的 Bug-fix，每个线上代码的 Bug-fix 都需要开一个 Hotfix 分支，完成后，向 Developer 分支和 Master 分支上合并。

合并完成后，删除 Hotfix 分支。

注意:

1. 我们需要长期维护 Master 和 Developer 两个分支。

2. 这其中的方式还是有一定复杂度的，尤其是 Release 和 Hotfix 分支需要同时向两个分支作合并。所以，如果没有一个好的工具来支撑的话，这会因为我们可

   能会忘了做一些操作而导致代码不一致。

idea:

创建完了新分支记得push到云仓库

指令:

git branch <新分支名>
1

checkout(切换分支):

切换分支之前一定要把本地改变提交push

idea:

或者:

指令:

git checkout <新分支名>
1

关于merge和rebase以下

介绍:

目前关于merge和rebase网上众说纷纭

合并操作简单,历史比较乱,如下图:

我们目前底下的子分支开发过程中需要依赖上面的主分支的代码C4,C6,C8, 此时我们有两个选择

合并和变基

合并(merge): 可以把main的合并到子分支上面子分支可以继续开发, 主还是主,从还是从,记录不变,内容合并

变基(rebase): 变更基础 可以把原来子分支的基点c2 变更到c8 ,

至于为啥很多开发者朋友很少使用rebase呢. 其实跟他的操作有点关系.

如果你rebase方向搞反了 ,就会变成main分支的所有提交的基点都变到子分支上面了.

这样容器出大问题.其他开发者拉取代码就会有问题.

不管是 rebase还是 merge, 当有代码冲突的时候都应该要处理了在合并 , 切记尽量不要使用强制推送

总结:

merge: 简单易操作, 历史稍微乱一点

rebase: 需要注意不要操作反了. 历史简单点

公司里面实际两个都会用 ,不要像网上那么极端: 把主线分支往独立分支上合并时用rebase 把独立分支往主线分支上合并时用merge

图示:

merge(合并):

把主分支变更到当前分支

合并前:

合并后:

这样做的目的是把主分支最新的变更合并到子分支,并且子分支可以继续开发

步骤:

1. 子分支,主分支都要保证跟云上一致最新,该pull 或者该push避免丢代码
2. 切换到子分支上面
3. 在子分支branchs 选择主分支 merge into current

idea操作:

切换两边分支push,pull保持和云仓库最新一致就不演示了 关键点:

指令操作:

git checkout feature
git merge main
1
2

或者一句指令:

git merge feature main
1

把功能做完了合并到主分支

这个时候主分支需要你得代码,所以需要正向操作(这才是merge的正确打开方式)

步骤:

1. 依然保持云上仓库本地仓库一致(切换两边分支 pull或者push),切记做任何操作都需要提交自己代码到云端.
2. 切换到目标分支(master或者dev).
3. 把选中分支(feature)合并到当前分支

idea操作:

指令操作:

git checkout main
git merge feature1
1
2

可以看到和上面刚好相反

远程请求合并:

一般应用于重要的发布上线功能测试等等

pull request pr

需要先提交给测试:

标准化流程是将自己的分支push到远程交给测试，当测试通过后，自己在gitlab上面创建合并请求，由测试统一审批处理合并

给测试准备一个feature分支的构建环境

测试只需要通过Jenkins构建你push上去的分支

测试服务器运行该项目 ,提测通过后, 统一审批处理合并然后

有些公司这一套基本要上线才会这样用, dev平常开发本地直接合了.

步骤:

1. 先把feature分支提交push到远程仓库
2. 去到gitee仓库填写pull request
3. 如果有冲突处理冲突 ,没有冲突测试ok统一合并

idea+gitee操作:

有冲突的话可以选择web ide 简单处理 或者使用

最终审查通过了点击合并分支即可

rebase(变基):

一定要注意不要把主分支rebase到子分支上面了 !!!

正确执行应该是:

在功能分支 rebase到目标分支

只能这样用:

指令操作:

git checkout feature
git rebase main
1
2

变基前:

变基后:

idea操作:

1. 切换到子分支
2. 右键git rebase 变基 , 变子分支的基础

永远不要

rebase命令会把main分支中的所有提交都放到feature分支的提交记录顶端。问题在于这个改变目前只出现在你的本地仓库。其他开发者仍然在原来的main分支上进行开发。由于rebase会产生全新的提交记录，所以Git会认为现在你本地的main分支与所有其他人的产生了分叉。

唯一能够同步两个不同的main分支的方式就是将其合并起来，这会产生一个冗余的合并提交，并且这次合并中的大部分提交内容都是相同的（以前的main分支和你本地的main分支中）。不用说，这下可真让人疑惑。

所以任何时候要执行git rebase命令之前，先确认“是否有其他人也正在使用此分支？”如果答案是确定的，那么你就应该停下来想想有没有其他非破坏性的操作（比如试试git revert命令）。除了这样的情况之外，重写提交历史都是安全的