git 详解及实用指南之三（分支管理）

时间  2019-11-10
标签 git 详解 实用 指南 之三 分支 管理 栏目 Git 繁體版
原文   原文链接

1. git 详解及实用指南之一 （本地操做）java

2. git 详解及实用指南之二 （远程操做）git

1.建立与合并分支

利用分支就能够实现多人开发的伟大模式，从而提升生产效率。在整个 GIT 之中，主分支(master)主要是做为程序 的发布使用，通常而言不多会在主分支上进行代码的开发，都会在各自的子分支上进行。github

1）mastr 分支segmentfault

默认状况下，mastr是一条线，git 利用 master 指向最新的提交，再用 "HEAD" 批向 "master",就能肯定当前分支以及当前分支的提交点。服务器

clipboard.png

以上操做属于项目发布版本的执行顺序，由于最终发布就是 master 分支。可是对于其它的开发者，不该该应该在mastr 分支上进行。因此应该创建分支，而子分支最起码创建的时候应该是当前的 master 分支的状态。而分支的一但建立以后， HEAD 指针就会发生变化。app

2）分支提交 学习

若是有新的提交，则 master 分支不会改变，只有 brh 分支会发生变化。测试

clipboard.png

那么此时 master 分支的版本号就落后于子分支了。可是无论子分支再怎么开发，也不是最新发布版本，全部的发布版本都保存在 master 分支上，那么就必须将分支与 master 的分支进行合并。fetch

3）分支提交 url

若是有新的提交，刚 master 分支不会改变，只有 bth 分支会发生改变。

clipboard.png

当分支合并以后，实际上就至关于 master 的分支的提交点修改成子分支的提交点，然后这个合并应该在 master 分支上完成，然后 HEAD 须要修改指针，断开 brh 分支，而指向本来的 master 分支。

4）删除子分支

若是有新的提交，刚 master 分支不会改变，只有 brh 分支会发生改变。

clipboard.png

分支删除掉以后全部的内容也就都取消了。

5）建立一个分支 

git branch brh

6）当分支建立完成以后能够经过以下命令进行察看 

git branch

clipboard.png

能够发现如今提示当前工做区中有两个分支:一个是 brh 分支，另一个是 master 分支，而如今的分支指向的 是 master 分支。

7）切换到brh分支 

git checkout brh

clipboard.png

可是不少时候咱们建立分支的最终目的就是为了切换到此分支上进行开发，因此为了方便操做，在 git 之中提供了一 个更加简单的功能。

建立并切换分支

若是想要删除子分支，那么不能在当前分支上，因此切换回了 master 分支

git checkgout master

删除子分支

git branch -d brh

创建分支的同时能够自动的切换到子分支

git checkout -b brh

8）切换到brh分支

如今已经成功的在brh分支上了，那么下面进行代码的修改;

修改 hello.js

btn.onclick = function() {
   console.log('git 分支管理练习！');
}

这个时候的 Hello.java 文件是属于子分支上的，而如今也在子分支上，那么下面查询一会儿分支的状态。

clipboard.png

此时更新的是子分支的内容，可是主分支上的数据呢?

9）在子分支上将修改进行提交 

git commit -a -m "modified hello.js file"

当子分支的数据提交以后实际上并不会去修改 master 分支的内容。这就证实了，两个分支上的内容是彼此独立的。

10）么既然分支都已经存在了，那么如今为了更加清楚，将master和brh两个分支都提交到远程服务器上(GITHUB) 

git remote set-url origin https://github.com/yootk/mldn.git 
git push origin master
git push origin brh

11）最终发布的版本必定是在master分支上，因此下面须要将brh分支与master分支进行合并(在主分支上)

git merge brh

clipboard.png

在以前讲解的时候说过其实是修改了 master 指针为 brh 分支的指针信息。因此此时的合并方式为“Fast-forward”,表示是快速合并方式，快速的合并方式并不会产生任何的 commit id。 它只是利用了合并子分支的 commit id 继续操做。

12）此时的brh分支没有任何的用处了，那么就能够执行删除操做

git branch -d brh

13）提交 master 分支

git push origin master

如今在本地上已经没有了子分支，可是在远程服务器上依然会存在子分支。那么下面要删除远程分支。

14）删除远程分支 

git push origin --delete brh

那么此时远程分支就已经被成功的删除掉了。

2.分支的操做管理

上面演示了分支的各个操做，包括使用分支、以及合并分支，同时也清楚了对于分支有两种方式一种 是本地分支，另一种是远程分支，可是对于分支在 GIT 使用之中依然会有一些小小的问题，因此下面进行集中式的说明：

1）为了方便仍是创建一个新的分支 —— brh

git checkout -b brh

2）在此分支上创建一些文件

public class HelloWorld() {
  console.log('Hello World');
}
git add .
    git commit -a -m "Add Emp.java File"

以上的代码是在子分支(brh)上创建的。

3）此时并无进行分支数据的提交，可是有人以为这个brh分支名称很差，应该使用本身的姓名简写完成“wzy”

git branch -m brh wzy

如今至关于分支名称进行了从新的命名。

4）将分支推送到远程服务器端

git push origin wzy

5）在本地察看远程的分支

// 察看所有的分支，包括远程和本地的分支
git branch -a 

// 只察看远程的分支
git branch -r

// 只察看本地分支
git branch -l

6）此时“wzt”分支上已经作出了修改，可是并无与master分支进行合并，由于如今所开发的功能开发到一半发现再也不须要了，因此就要废除掉所做出的修改。因而发出了删除 wzy 分支的命令

git branch -d wzy

clipboard.png

此时直接提示，分支并不可以被删除掉，由于这个分支所作出的修改尚未进行合并。若是要想强制删除此分支， 则可使用“-D”的参数完成。

clipboard.png

但是如今在远程服务器上依然会存在此分支，那么就必须也一块儿删除掉，可是对于删除操做，除了以前使用过的方 式以外，也能够推送一个空的分支，这样也表示删除。

删除方式一

git push origin --delete wzy

删除方式二

git push origin :wzy

3.冲突解决

分支能够很好的实现多人开发的互操做，可是有可能出现这样种状况:

  • 如今创建了一个新的分支 brh，而且有一位开发者在此分支上修改了 hello.js 文件。
  • 可是这个开发者因为不当心的失误，又将分支切换回了 master 分支上，而且在 master 分支上也对 hello.js文件进行修改。

等于如今有两个分支对同一个文件进行了修改，那么在进行提交的时候必定会出现一个冲突。由于系统不知道到底 提交那一个分支的文件。

master 和 brh 两个分支上都有各自的信息提交，那么此时就造成了冲突：

clipboard.png

那么很明显，此时有两个提交点，那么会出现怎样的冲突警告呢?为了更好的说明问题，下面经过代码进行验证:

1）创建并切换到 brh 分支上

git checkout -b brh

2）在此分支上修改hello.js文件

btn.onclick = function() {
   console.log('git 分支管理练习！');
   console.log('git 分支冲突练习！')
}

3）在brh分支上提交此文件 

git commit -a -m "add static attribute"

4）切换回 master 分支 

git checkout master

5）在 master 分支上也修改 Hello.js 文件 

btn.onclick = function() {
   console.log('git 分支管理练习！');
   console.log('git Mast 分支修改测试！ ')
}

6）在master分支上进行修改的提交 

git commit -a -m "add master change file"

如今在两个分支上都存在了代码的修改，并且很明显，修改的是同一个文件，那么天然进行分支合并的时候是没法 合并的。

7）合并分支(此时已经存在于master分支上) 

git merge brh

clipboard.png

此时会直接提示出现了冲突。

8）察看冲突的内容

clipboard.png

直接提示用户，两次修改了 Hello.java 文件。

9） 察看 Hello.js 文件 

btn.onclick = function() {
   console.log('git 分支管理练习！');
<<<<<<< HEAD
   console.log('git Mast 分支修改测试！ ')
=======
   console.log('git 分支冲突练习！')
>>>>>>> brh
}

它如今把冲突的代码进行了标记，那么如今就必须人为手工修改发生冲突的文件。

10）手工修改 Hello.js 文件 

btn.onclick = function() {
   console.log('git 分支管理练习！');
   console.log('git Mast 分支修改测试！ ')
   console.log('git 分支冲突练习！')
}

如今是但愿这几个输出的内容都同时进行保留。

11）此时已经手工解决了冲突，然后继续进行提交 

git commit -a -m "conflict print"

那么如今的冲突问题就解决了。

12）向服务器端提交信息 

git push origin master

那么在实际的开发之中，必定会存在有许多的分支合并的状况，那么我怎么知道分支合并的历史呢?

13） 察看合并的状况 

git log --graph --pretty=oneline

clipboard.png

“-graph”指的是采用绘图的方式进行现实。

14） 删除掉 brh 分支 

git branch -d brh

那么此时的代码就能够回归正常的开发模式。

4.分支管理策略

在以前进行分支合并的时候使用的所有都是“Fast forward”方式完成的，而此种方式只是改变了master指针，但是 在分支的时候也能够不使用这种快合并，即:增长上一个“--no-ff”参数，这样就表示在合并以后会自动的再生成一个新 的 commit id，从而保证合并数据的完整性。

"-no-ff": 合并后动建立一个新的 commit

clipboard.png

1）建立一个新的分支 

git checkout -b brh

2）创建一个新的 empty.js 文件 

public class Empty() {
  console.log('empty file');
}

3） 提交修改 

git add.
git commit -m "add empty.js file"

4） 切换回master分支 

git checkout master

5） 使用非快速合并的方式进行代码合并 

git merge --no-ff -m "no ff commit" brh

“--no-ff”方式会带有一个新的提交，因此须要为提交设置一个提交的注释。

6） 察看一下提交的日志信息 

git log --graph --pretty=oneline --abbrev-commit

clipboard.png

分支策略

  • master 分支应该是很是稳定的，也就是仅用来发布新的版本，不要在此分支上开发；
  • 在各个子分支上进行开发工做；
  • 团队中的每一个成员都在各个分支上工做；

clipboard.png

5.分支暂存

譬如说同在你正在一个分支上进行代码的开发，可是忽然你的领导给了你一个新的任务，而且告诉你在半个小时内 完成，那么怎么办?

难道那开发一半的分支要提交吗?不可能的，由于对于版本控制的基本的道德方式:你不能把有问题的代码提交上 去，你所提交的代码必定都是正确的代码，那么为了这样的问题，在 GIT 中提供了一个分支暂存的机制，能够将开发一半 的分支进行保存，然后在适当的时候进行代码的恢复。

那么下面首先建立一个基本的开发场景。

1）建立并切换到一个新的分支 

git checkout -b brh

2）下面在分支上编写empty.js 类的文件 

public class Empty() {
  console.log('empty file');
  console.log('我正在开发一半中。。。。。。')
}

3）将此文件保存在暂存区之中 

git add .

这个时候因为代码尚未开发完成，因此不可以进行代码的提交。可是你的老板给了你一个新的任务，那么你就不得不去中止当前的开发任务，因此就须要将当前的开发进度进行“暂存”，等往后有时间了继续进行恢复开发。

4）将工做暂存 

git stash

clipboard.png

5）察看一下当前的工做区中的内容

clipboard.png

此处会直接告诉用户当前的工做区之中没有任何的修改。

6）察看一下当前的工做区中的内容

然后如今假设要修改的代码还处于master分支上，因此下面切换到master分支。

那么如今假设说建立一个新的分支，用于完成老板的需求，假设分支的名称为“dev”(也有多是一个 bug 调试)。

7）建立并切换分支 

git checkout -b dev

8） 在新的分支中修改Hello.js文件 

btn.onclick = function() {
   console.log('git 分支管理练习！');
   console.log('git Mast 分支修改测试！ ')
   console.log('git 分支冲突练习！')
   console.log('临时任务 dev 上的修改')
}

9） 提交修改的操做 

git commit -a -m "dev change"

10） 提交修改的操做

合并 deve 分支，使用 no fast forward

git merge --no-ff-m "merge dev branch" dev

11） 那么如今突发的问题已经被解决了，被解决以后对于 dev 的分支将没有任何的存在乎义，能够直接删除; 

git branch -d dev

12） 那么须要回归到已有的工做状态，可是有可能会存在有许多的暂存的状态，能够直接使用以下命令进行列出。 

git stash list

clipboard.png

13）从暂存区之中进行恢复

暂存区恢复以后那么所暂停的操做将没有存在的意义，可是也有人会认为它有意义，因此对于恢复有两种形式:

形式一:先恢复，然后再手工删除暂存

git stash apply
git stash drop

形式二:恢复的同时也将 stash 内容删除

git stash pop

clipboard.png

那么下面的任务就能够像以前那样进行代码的提交，然后删除掉 brh 分支:

git commit -a -m "change empty.js"
git branch -d brh

使用暂存策略能够很方便的解决代码忽然暂停修改的操做，是很是方便。

6.补丁: patch

补丁并非针对于全部代码的修改，只是针对于局部的修改。在不少的代码维护之中，若是按照最先克隆的方式将 代码总体克隆下来实际上所花费的资源是很是庞大的，可是修改的时候可能只修改很小的一部分代码，因此在这种状况下 就但愿能够将一些代码的补丁信息发送给开发者。而发给开发者以后他须要知道那些代码被修改了，这样的话就可使用 一个极低的开销实现代码的修改操做，而在 GIT 之中也提供了两种简单的补丁方案:

  • 使用 git diff 生成标准的 patch
  • 使用 git format-patch 声称 git 专用的 patch

1） 利用 git diff 生成标准的 patch

当前的empty.js文件

public class Empty() {
  console.log('empty file');
  console.log('我正在开发一半中。。。。。。')
}

2） 创建一个新的分支 —— cbrh 

git checkout -b cbrh

3） 修改 empty.js文件 

public class Empty() {
  console.log('empty file');
  console.log('我正在开发一半中。。。。。。')

  console.log('补丁修改1');
  console.log('补丁修改2');
}

4） 然后察看先后代码的不一样 

git diff empth.js

clipboard.png

此时能够发现 Emp.java 文件修改先后的对比状况。

5） 在cbrh上进行代码的提交 

git commit -a -m "add 2 line empty.js "

此时并无和主分支进行提交，可是代码已经改变了，须要的是将代码的变化提交给开发者。

6） 生成补丁文件 —— mypatch 

git diff master > mypatch

7）切换回master分支

此时会自动在项目目录中生成一个 mypat 的补丁文件信息。这个文件是能够由 git 读懂的信息文件，那么完成以后如今须要模拟另一个开发者，另一个开发者假设是专门进行补丁合并的开发者。

8）建立并切换一个新的分支 

git checkout -b patchbrh

9）应用补丁信息 

git apply mypatch

此时补丁能够成功的使用了。

10）提交补丁的操做 

git commit -a -m "patch apply"

11）切换回 master 分支之中进行分支合并 

git checkout master
git merge --no-ff -m "Merge Patch" patchbrh

这样若是只是将补丁数据的文件发送给开发者，那么就没有必要进行大量代码的传输，而且在建立补丁的时候也能够针对于多个文件进行补丁的建立。

7. 利用 git format-patch 生成 GIT 专用补丁

1）建立并切换到cbrh分支 

git branch -D cbrh
git branch -D patchbrh 
git checkout -b cbrh

2）建立并切换到cbrh分支 

public class Empty() {
  console.log('empty file');
  console.log('git format-patch 测试')
}

3）建立并切换到cbrh分支 

git commit -a -m "add formatch test"

4）下面须要与原始代码作一个比较，并且比较后会自动的生成补丁文件 

git format-patch -M master

如今表示要与 master 分支进行比较(而-M 参数就是指定分支)。

clipboard.png

此时已经生成了一个补丁文件，由于只修改了一次的内容。这个补丁文件严格来将就是一个 email 数据，须要将此数据发送给开发者，然后开发者能够进行补丁的应用。

5）建立并切换到patchbrh分支上 

git checkout master
git checkout -b patchbrh

6） 应用补丁的信息，利用“git am”完成 

git am 0001-add-formatch-test.patch

clipboard.png

如今是将发送过来的，带有 email 格式的补丁文件进行了应用。

7） 提交应用的更新

git commit -a -m "method patch apply"

那么此时就能够成功的应用补丁进行代码的更正。

关于两种补丁方式的说明

  • 使用git diff生成补丁兼容性是比较好的，若是你是在不是git管理的仓库上，此类方式生成的补丁是很是容易接受的;
  • 可是若是你是向公共的开发社区进行代码的补丁更正，那么建议使用git format-patch，这样不只标准，并且也能够将更正人的信息进行公布。

8. 多人协做开发

分支的处理其实是为了更好的多人开发作出的准备，那么下面就将利用两个命令行方式(模拟其余的开发者)进行项目代码的编写。首先说明一下:

  • 通常而言，master 分支项目的核心分支，只要进行代码的克隆，那么此分支必定会被保存下来;
  • 开发者每每会创建一系列的分支，譬如，本次练习创建了一个 brh 的分支进行代码的编写;
  • 若是要进行调试能够创建一个 bug 分支;
  • 若是要增长某些新的功能则能够创建 feature 分支。

1） 建立并切换到一个新的分支:brh 

git checkout -b brh

2) 在新的分支上创建一个新的文件 —— Dept.js

public class Dept() {
  console.log('多人协做开发!');
}

3) 将此代码进行提交 

git commit -a -m 'add dept.js files'

4) 将两个分支提交到服务器上去 

git push origin master    
git push origin brh

5） [二号]为了模拟第二个开发者，因此创建一个新的命令行窗口，而且将代码复制下来(d:proclone) 

git clone https://github.com/qq449245884/HelloGitHub.git

6) [二号] 察看分支信息 

git branch -a

clipboard.png

发现如今只是将 master 分支拷贝下来了，可是 brh 分支并无存在。

7) [二号]创建并切换到brh分支上 

git checkout -b brh

8) [二号]将远程服务器端上的brh分支的内容拷贝到本地的brh分支上 

git merge origin/brh

9) [二号]如今开发者增长了一个Admin.js文件 

public class Admin() {
  console.log('多人协做测试!:')
}

10) [二号]将新的代码进行提交 

git add .
git commit -m 'add admin.js files'

11) [二号]如今本地的 brh 分支代码发生了变化，那么应该将此变化提交到远程的 brh 分支上 

git push origin brh

如今代码已经发送到了服务器上了，而且在 brh 分支上增长了新的 Admin.java 文件。

12) [一号]这个时候最原始的开发者目录下还只是上一次提交的内容。那么须要取得最新的数据才能够

对于取得最新的分支数据有两种方式:

  • git fetch: 此操做只是取得最新的分支数据，可是不会发生 merge 合并操做
  • git pull: 此操做取出最新分支数据，而且同时发生 merge 合并操做

    git pull

clipboard.png

实际上错误信息也很简单，指的是，当前的 brh 分支和服务器上的分支没有关系，因此若是要想读取代码，必须让两 个分支产生关联关系。

git branch --set-upstream-to=origin/brh

随后再次读取全部的代码。

13) [二号]修改 Admin.js 类文件 

public class Admin() {
  console.log('多人协做测试!:')
  console.log('二号我来个性了！');
}

14) [二号]将以上的代码进行提交 

git commit -a -m 'update admin.js file'

15) [二号]向服务器端提交代码的修改

git push origin brh

16) [一号]开发者也进行 Admin.js 文件的修改

public class Admin() {
  console.log('多人协做测试!:')
  console.log('一号也进行修改了!')
}

17) [一号]将代码提交

git commit -a -m "1 update admin.js file"

可是这个时候很明显，两个用户一块儿修改了同一个文件。

18) [一号]抓取最新的更新数据

git pull

clipboard.png

如今能够发现，此时的程序，是两位开发者修改了同一个代码，因此产生了冲突。同时一号开发者之中的 Admin.js 文件的内容已经变动为以下情:

public class Admin() {
  console.log('多人协做测试!:')
<<<<<<< HEAD
  console.log('一号也进行修改了!')
=======
  console.log('二号我来个性了！');
>>>>>>> a600e113d2d139efc73eee2052ad509fa95d16e3
}

19) [一号]手工解决冲突文件内容

public class Admin() {
  console.log('多人协做测试!:')
  console.log('一号也进行修改了!')
  console.log('二号我来个性了！');
}

20) 再次执行提交和服务器推送

git commit -a -m "3 Update Admin.js File" 
 git push origin brh

如今已经成功的由本地的冲突扩充到了远程的冲突，相信经过一系列的代码你们也能够更好的理解分支的操做问题。

你的点赞是我持续分享好东西的动力，欢迎点赞！

一个笨笨的码农，个人世界只能终身学习！

更多内容请关注公众号《大迁世界》！

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程