| |
|
开发:
C++知识库
Java知识库
JavaScript
Python
PHP知识库
人工智能
区块链
大数据
移动开发
嵌入式
开发工具
数据结构与算法
开发测试
游戏开发
网络协议
系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程 数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁 |
-> 开发工具 -> git的分支管理 -> 正文阅读 |
|
[开发工具]git的分支管理 |
一、情景????????在我们日常开发中,假设接到一个新的功能开发的需求给了你两周的时间进行你开发,这一周你完成了65%的代码,这时候便会面临着这么一个问题:如果我这时候提交,但是代码还没有写完也就是不完整的代码,你提交的话便会便使得代码库变得不完整,从而影响了其他同事的开发。这时你又想,那要不等我开发完毕再提交代码好了?但是问题又来了,你能保证你本地的电脑不会挂机吗(狗头.jpg),同时也有着丢失进度的风险。 现在有了git的分支管理,就大大解决了这个问题。也就是你开发的时候,你创建属于你的分支,别人是看不到的。正是因为这种独立性,各个分支之间的开发工作互不打扰,所以你在你的分支上干活,想提交就提交,知道开发完毕之后,再一次合并到原来的分支上,这样便解决了既安全又不会影响别人的工作的问题。 二、创建分支与合并分支我们知道,一个项目只允许有一个主分支,通常用来合并其他开发完毕的分支的。因此我们日常的开发工作都是在其他分支下完成的。 首先,我们创建dev分支,然后切换到dev分支:
git checkout命令加上-b参数表示创建并切换,相当于一下两条命令:
然后使用git branch命令查看当前分支:
git branch命令会列出所有的分支,当前分支面前会标有一个*号 然后,我们就可以在dev分支上正常提交,比如对readme.txt做个修改,然后提交:
现在,dev分支上的工作完成,我们就可以切换回master分支:
切换回master分支,你可以查看一下readme.txt文件,你会发现刚才你再dev分支下修改的内容,这master分支下是看不到的!原因是,(在合并分支之前)各个分支时独立开来的,master分支同样是,刚才的提交是在dev分支上,所以master分支上是看不到的。因此,如果想看到dev分支下的修改,把dev分支的工作成果合并到master分支上即可:(注意:当前分支是master)
?git merge name命令用于合并指定分支到当前分支,合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的,合并完成后,就可以放心的删除dev分支了(当然你也可以选择不删除)
删除后,查看branch,就剩下master分支了
注意: ?git merge?命令用于合并指定分支到当前分支:这里我要提一下,这里所说的将指定分支合并到当前分支,这个当前分支不一定是master分支,可以是任意分支,只要使用checkout切换的当前所在分支都可以。git merge name中的name就是你想要合并的分支。 在工作中的通常操作是,某个大的模块你创建为分支feature-user-v1.0.0,然后这个大的模块下又有很多小模块,你想细化的话,你可以进行如下操作 首先: 1.创建并切换到feature-user-v1.0.0分支下? ??
2.这时候分支指针指向的就是feature-user-v1.0.0分支,然后在当前分支创建一个新的分支(小模块)
3.在这个新分支下开发,开发完毕之后提交 4.然后切换回feature-user-v1.0.0分支,合并这个小模块的分支git merge?feature-userMoudle 5.之后删除这个小模块的分支 三、bug分支? ? ? ? 在我们开发工作中,每个bug都可以通过一个新的临时分支来修复,修复后。合并分支,然后将临时分支删除。 情景:你接到一个修复代号为101的bug的任务时,你很自然的想创建一个分支'hotfix-issue-101',来修复它,但是,你当前正在dev上进行的工作还没有提交,并不是你不想提交,而是工作只是进行了一般,还没发提交,预计完成还需要1天的时间,但是这个bug必须在2个小时内修复完毕,怎么办? 幸好的是,git还提供了stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
执行了git stash之后,再执行git sttaus命令查看,此时的工作区是干净的(除非有没有被git管理的文件),因此可以放心的创建分支来修复bug 接着,我们就要确定在哪个分支上修复bug,假定需要在master分支上修复,就从master上创建临时分支(其他分支同理) 1.切换到要修改bug的分支,然后在该分支下创建一个新的分支并切换到这个新创建的分支上
2.修改工作进行完毕之后,进行提交
3.然后切换到mster分支,进行合并
4.然后删除这个临时创建的分支(可选,一般都会删除) 5.现在接着回到dev分支干活
git status查看分支状态的时候,分支是干净的,那么刚才的工作现场存到哪里去了呢?使用git stash list命令look look:
工作现场还在,git把stash内容存在某个地方了,所以需要恢复一下,有两个方法:
再用git stash list查看,就不会看到任何stash的内容了
接着就可以在dev分支上正常进行继续的开发工作了! 注意:在master分支上修复bug后,我们要想一想,dev分支是早期从master分支分出来的,所以这个bug其实在当前dev分支上也存在 那么在dev分支上修复同样的bug?重复操作一次,提交不在行了?有没有更简单的方法? 有! 同样的bug,要在dev上修复,我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支, ?注意,我们只想复制4c805e2 fix bug 101这个提交所做的修改,并不是把整个master分支merge过来。 为了方便操作,git提供了一个cherry-pick命令,让我们能复制一个特定的提交到当前分支:
????????git自动给dev分支做了一次提交,注意这次提交的commit是1d4b803,它不同于master的4c805e2,因为这两个commit只是改动相同,但确实是两个不同的commit,用git-cherry-pick,我们就不需要哟啊在dev分支上手动再把bug的过程重复一遍。 ? ? ? ? 我当时是这样想的:既然可以在master分支上修复bug后,在dev分支上可以“重放”这个修复过程,那么直接在dev分支上修复bug,然后在master分支上"重放”行不行?当然可以,不过你扔需要git stash命令保存现场,才能从dev分支切换到master分支上。 小结: 修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除; 当手头工作没有完成时,先把工作现场git stash一下,然后修复bug,修复后,在git stash pop,回到工作现场; master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick <commit>命令,把bug提交的修改“复制”到当前分支,避免重复劳动 四、Feature分支? ? ? ? 在软件开发中,总会有无穷无尽的新功能要不断添加进来。所以,没添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。 ? ? ? ? 比如,你现在接到一个新的任务,开发代号为new,于是开始下面的开发工作: 1.首先新建一个feature分支,并切换到该分支上
2.然后在该分支上进行开发,开发完毕后,提交相应的文件
3.然后切换回dev,准备合并
4.然后进行合并,然后删除该feature分支(可删可不删) 五、多人合作? ? ? ? 当你从远程仓库克隆时,实际上git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin 要查看远程仓库的信息,用git remote:
或者,使用git remot -v显示更详细的信息:
上面显示了可以抓取和推送的origin的地址,如果没有推送权限,就看不到push的地址 ?1.推送分支? ? ? ? 推送分支(git push origin name),就是把该分支上的所有本地提交的推送到远程仓库,推送时,要指定本地分支,这样,git就会把该推送到远程库对应的远程分支上:
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
总之,在git中,分支完全可以在本地自己藏着玩,是否推送,根据你自身情况而定! 2.抓取分支?? ? ? ? 多人协作时,大家都会往master和dev分支上推送各自的修改,现在模拟你的一个小伙伴,可以在另外一台电脑或者再同台电脑的另一个目录下戈隆
当你的小伙伴从远程clone时,默认情况下,你的小伙伴只能看到本地的master分支,不信你可以git branch命令看看: ?
现在,你的小伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,也是他用这个命令创建本地dev分支:
现在,他就可以在dev上继续修改,然后,是不是把dev分支push到远程:
你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件做了修改,试图推送:
推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决方法也很简单,git已经提示我们,先用git pull把最新提交从origin/dev抓下来,然后在本地合并,解决冲突,再推送
git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,距提示,设置dev和origin/dev的链接:
然后再进行pull
这回git pull成功,但是合并冲突,需要手动解决,解决的方法就是和分支管理中的解决冲突方法一样,解决后,提交,再push:
3.小结多人协作模式通常是这样的: 1.首先可以试图用git push origin <branch-name>推送自己的修改; 2.如果推送失败,需要先用git pull试图合并 3.如果有冲突,则解决冲突,并在本地提交; 4.没有冲突或者解决掉冲突后,在用git push origin <branch-name> 推送就能成功! tip:如果 这就是多人协作的工作模式,一旦熟悉了,就非常简单。 |
|
|
上一篇文章 下一篇文章 查看所有文章 |
|
开发:
C++知识库
Java知识库
JavaScript
Python
PHP知识库
人工智能
区块链
大数据
移动开发
嵌入式
开发工具
数据结构与算法
开发测试
游戏开发
网络协议
系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程 数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁 |
360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年11日历 | -2024/11/26 0:44:00- |
|
网站联系: qq:121756557 email:121756557@qq.com IT数码 |