当前位置:   article > 正文

git版本管理(创建、删除、查看、合并分支)_git 删除feature文件

git 删除feature文件

0 背景

本文内容总结自gitcode的git入门。

1 分支基本概念

单分支:

一开始的时候,master分支是一条线,Git 用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:

请添加图片描述

每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。

多分支:

当我们创建新的分支,例如dev时,Git 新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev

你看,Git 创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化!

请添加图片描述

不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:

请添加图片描述
分支合并

把master指向dev的当前提交,就完成了合并, Git 合并分支也很快!就改改指针,工作区内容也不变!

请添加图片描述

合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支:

请添加图片描述

2 分支管理

2.1 创建分支

  • 使用git checkout:
$ git checkout -b dev
Switched to a new branch 'dev'
  • 1
  • 2

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:

$ git branch dev
$ git checkout dev
Switched to branch 'dev'
  • 1
  • 2
  • 3
  • 使用git switch :

创建并切换到新的dev分支,可以使用:

$ git switch -c dev
  • 1

注意⚠️:
git switchgit checkout在分支操作方面的用处完全一样。那么可以在分支操作上尽量光用git branchgit switch
因为git checkout除了可以操作分支,它还可以操作文件(可以重写工作区)。

2.2 查看分支

$ git branch
* dev
  master
  • 1
  • 2
  • 3

2.3 合并分支

git merge命令:用于合并指定分支到当前分支。

# 切换回当前的分支:
$ git checkout master
Switched to branch 'master'

# 合并到指定分支:
$ git merge dev
Updating 599dbdb..4aac6c7
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

上面使用的是Fast forward模式(“快进模式”),但这种模式下,删除分支后,会丢掉分支信息。

如果要强制禁用Fast forward模式,Git 就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

  • 1
  • 2
  • 3
  • 4
  • 5

合并后的结果如下:
请添加图片描述

2.4 删除分支

$ git branch -d dev
Deleted branch dev (was 4aac6c7).
  • 1
  • 2

3 解决合并冲突

冲突情况发生的情况如下图所示,Git 无法执行“快速合并”,必须手动解决冲突后再提交。
在这里插入图片描述
合并冲突后的结果:

在这里插入图片描述

3.1 在git官网上解决

点击合并请求,选择我们需要的分支内容,然后选择合并。
请添加图片描述

3.2 本地解决

  • 步骤一. 拉取并检查用于合并的分支
git fetch origin
git checkout -b "feature1" "origin/feature1"
  • 1
  • 2
  • 步骤二. 在本地查看并做更改

Git 用<<<<<<<,=======,>>>>>>>标记出不同分支的内容,例如下面的内容:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 步骤三. 合并分支并解决冲突
git fetch origin
git checkout "master"
git merge --no-ff "feature1"
  • 1
  • 2
  • 3
  • 步骤四. 推送代码并合并
git push origin "master"
  • 1

其他方法为:

  • 法1:

保留本地最新修改,并拉取仓库中 的代码到本地

git stash  
git pull origin master  
git stash pop 
  • 1
  • 2
  • 3
  • 法2:
    放弃本地代码,新修改的都不要了,退回上一版本,再拉取代码到本地
git reset --hard  
git pull origin master  

# 或
git fetch --all
git reset --hard origin/master 
git pull
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

4 分支转移

git cherry-pick命令的作用,就是将指定的提交commit应用于其他分支。

$ git cherry-pick \<commitHash\>
  • 1

上面命令就会将指定的提交commitHash,应用于当前分支。这会在当前分支产生一个新的提交,当然它们的哈希值会不一样。

举例来说,代码仓库有masterfeature两个分支。

 a - b - c - d Master
 \\
 e - f - g Feature
  • 1
  • 2
  • 3

现在将提交f应用到master分支。

\# 切换到 master 分支
$ git checkout master

\# Cherry pick 操作
$ git cherry-pick f
  • 1
  • 2
  • 3
  • 4
  • 5

上面的操作完成以后,代码库就变成了下面的样子。

 a - b - c - d - f Master
 \\
 e - f - g Feature
  • 1
  • 2
  • 3

从上面可以看到,master分支的末尾增加了一个提交f。

git cherry-pick命令的参数,不一定是提交的哈希值,分支名也是可以的,表示转移该分支的最新提交。

$ git cherry-pick feature
  • 1

上面代码表示将feature分支的最近一次提交,转移到当前分支。

Cherry pick 支持一次转移多个提交。

$ git cherry-pick \<HashA\> \<HashB\>
  • 1

上面的命令将 AB 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。

如果想要转移一系列的连续提交,可以使用下面的简便语法。

$ git cherry-pick A..B 
  • 1

上面的命令可以转移从 AB 的所有提交。它们必须按照正确的顺序放置:提交 A 必须早于提交 B,否则命令将失败,但不会报错。

注意,使用上面的命令,提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A,可以使用下面的语法。

$ git cherry-pick A^..B 
  • 1
`git cherry-pick`命令的常用配置项如下。

#### -e,--edit

打开外部编辑器,编辑提交信息。

#### -n,--no-commit

只更新工作区和暂存区,不产生新的提交。

#### -x

在提交信息的末尾追加一行`cherry picked from commit ...`,方便以后查到这个提交是如何产生的。

#### -s,--signoff

在提交信息的末尾追加一行操作者的签名,表示是谁进行了这个操作。

#### -m parent-number,--mainline parent-number

如果原始提交是一个合并节点,来自于两个分支的合并,那么 `Cherry pick` 默认将失败,因为它不知道应该采用哪个分支的代码变动。

`-m`配置项告诉 Git,应该采用哪个分支的变动。它的参数`parent-number`是一个从1开始的整数,代表原始提交的父分支编号。

```bash
$ git cherry-pick -m 1 \<commitHash\>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26

上面命令表示,Cherry pick 采用提交commitHash来自编号1的父分支的变动。

一般来说,1号父分支是接受变动的分支,2号父分支是作为变动来源的分支。

如果操作过程中发生代码冲突,Cherry pick 会停下来,让用户决定如何继续操作。

(1)–continue

用户解决代码冲突后,第一步将修改的文件重新加入暂存区(git add .),第二步使用下面的命令,让 Cherry pick 过程继续执行。

$ git cherry-pick --continue
  • 1

(2)–abort

发生代码冲突后,放弃合并,回到操作前的样子。

(3)–quit

发生代码冲突后,退出 Cherry pick,但是不回到操作前的样子。

Cherry pick 也支持转移另一个代码库的提交,方法是先将该库加为远程仓库。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/665997
推荐阅读
相关标签