如何建立一个网站app,网站建设的具体奖罚措施,华宇网站建设,wordpress 侧边收起文章目录 前言一、Git的分支管理策略 1.1 Fast forward 模式和--no-ff 模式 1.2 企业分支管理策略二、bug分支三、删除临时分支四、总结总结 前言 一、Git的分支管理策略
1.1 Fast forward 模式和--no-ff 模式 通常合并分支时#xff0c;如果可能#xff0c;Git 会… 文章目录 前言一、Git的分支管理策略 1.1 Fast forward 模式和--no-ff 模式 1.2 企业分支管理策略二、bug分支三、删除临时分支四、总结总结 前言 一、Git的分支管理策略
1.1 Fast forward 模式和--no-ff 模式 通常合并分支时如果可能Git 会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后形成的合并结果是什么呢回顾一下 图示说明 在这种 Fast forward 模式下删除分支后查看分支历史时会丢掉分支信息看不出来最新提交到底是 merge 进来的还是正常提交的。 但在合并冲突部分我们也看到通过解决冲突问题会再进行一次新的提交得到的最终状态为 图示说明 那么这就不是 Fast forward 模式了这样的好处是从分支历史上就可以看出分支信息。 例如我们现在已经删除了在合并冲突部分创建的 dev1 分支但依旧能看到 master 其实是由其他分支合并得到。 代码示例 hyb139-159-150-152:~/gitcode$ git log --graph --prettyoneline --abbrev-commit * 2976afc (HEAD - master) merge ReadMe |\ | * c594fd1 modify ReadMe * | c10f6d0 modify ReadMe |/ Git 支持我们强制禁用 Fast forward 模式那么就会在 merge 时生成一个新的 commit 这样从分支历史上就可以看出分支信息。 下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。 步骤一 ⾸先创建新的分支 dev2 并切换至新的分支: 代码示例 hyb139-159-150-152:~/gitcode$ git checkout -b dev2 #切换到分支dev2 Switched to a new branch dev2 步骤二修改 ReadMe 文件并提交一个新的 commit : 代码示例 hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d #修改文件信息 hyb139-159-150-152:~/gitcode$ git add . hyb139-159-150-152:~/gitcode$ git commit -mmodify ReadMe [dev2 41b082f] modify ReadMe 1 file changed, 1 insertion() 步骤三切回 master 分支通过开始--no-ff 方式合并 代码示例 hyb139-159-150-152:~/gitcode$ git checkout master Switched to branch master hyb139-159-150-152:~/gitcode$ git merge --no-ff -m merge with no-ff dev2 Merge made by the recursive strategy. ReadMe | 1 1 file changed, 1 insertion() hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d 请 注意 --no-ff 参数表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建 一个新的 commit 所以加上 -m 参数把描述写进去。 步骤四合并后查看分支历史 代码示例 hyb139-159-150-152:~/gitcode$ git log --graph --prettyoneline --abbrev-commit * 5bd16b4 (HEAD - master) merge with no-ff |\ | * 41b082f (dev2) modify ReadMe |/ 可以看到不使用 Fast forward 模式merge后就像这样 图示示例 总结 所以在合并分支时加上 --no-ff 参数就可以用普通模式合并合并后的历史有分支能看出来曾经做过合并而 fast forward 合并就看不出来曾经做过合并。 1.2 企业分支管理策略 在实际开发中我们应该按照几个 基本原则进行分支管理 首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活 那在哪⼲活呢 干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布 时再把dev分支合并到master上在master分支发布1.0版本 你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了。 图示示例 所以团队合作的分支看起来就像这样 二、bug分支 假如我们现在正在 dev2 分支上进行开发开发到一半突然发现 master 分支上面有 bug需要解决。 在Git中每个 bug 都可以通过一个新的临时分支来修复修复后合并分支然后将临时分支删除。 可现在 dev2 的代码在工作区中开发了一半还无法提交怎么办 代码示例 hyb139-159-150-152:~/gitcode$ git branch * dev2 master hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d i am coding ... #dev2 的代码在工作区中开发了一半 hyb139-159-150-152:~/gitcode$ git status On branch dev2 Changes not staged for commit: (use git add file... to update what will be committed) (use git restore file... to discard changes in working directory) modified: ReadMe no changes added to commit (use git add and/or git commit -a) Git 提供了 git stash 命令可以将当前的⼯作区信息进⾏储藏被储藏的内容可以在将来某个时间恢复出来。 代码示例 hyb139-159-150-152:~/gitcode$ git stash Saved working directory and index state WIP on dev2: 41b082f modify ReadMe hyb139-159-150-152:~/gitcode$ git status On branch dev2 nothing to commit, working tree clean 用 git status 查看工作区就是干净的除非有没有被 Git 管理的文件因此可以放心地创建分支来修复bug。 储藏 dev2 工作区之后由于我们要基于master分支修复 bug所以需要切回 master 分支再新建临时分支来修复 bug。 代码示例 hyb139-159-150-152:~/gitcode$ git checkout master # 切回master Switched to branch master hyb139-159-150-152:~/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分⽀ Switched to a new branch fix_bug hyb139-159-150-152:~/gitcode$ vim ReadMe hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e # 修复bug--忘记写e hyb139-159-150-152:~/gitcode$ git add ReadMe # 重新addcommit hyb139-159-150-152:~/gitcode$ git commit -mfix bug [fix_bug 4bbc0c4] fix bug 1 file changed, 1 insertion(), 1 deletion(-) 修复完成后切换到 master 分⽀并完成合并最后删除 fix_bug 分⽀ 代码示例 hyb139-159-150-152:~/gitcode$ git checkout master Switched to branch master hyb139-159-150-152:~/gitcode$ git merge --no-ff -mmerge fix_bug branch fix_bu Merge made by the recursive strategy. ReadMe | 2 - 1 file changed, 1 insertion(), 1 deletion(-) hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e hyb139-159-150-152:~/gitcode$ git branch -d fix_bug Deleted branch fix_bug (was 4bbc0c4). ⾄此bug 的修复⼯作已经做完了我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀ 代码示例 hyb139-159-150-152:~/gitcode$ git checkout dev2 Switched to branch dev2 hyb139-159-150-152:~/gitcode$ git status On branch dev2 nothing to commit, working tree clean ⼯作区是⼲净的刚才的⼯作现场存到哪去了 ⽤ git stash list 命令看看 代码示例 hyb139-159-150-152:~/gitcode$ git stash list stash{0}: WIP on dev2: 41b082f modify ReadMe ⼯作现场还在Git 把 stash 内容存在某个地⽅了但是需要恢复⼀下如何恢复现场呢我们可以使⽤ git stash pop 命令恢复的同时会把 stash 也删了 代码示例 hyb139-159-150-152:~/gitcode$ git stash pop On branch dev2 Changes not staged for commit: (use git add file... to update what will be committed) (use git restore file... to discard changes in working directory) modified: ReadMe no changes added to commit (use git add and/or git commit -a) Dropped refs/stash{0} (4f873250b3503687b5efd26196776aee7e3724c2) 再次查看的时候我们已经发现已经没有现场可以恢复了 代码示例 hyb139-159-150-152:~/gitcode$ git stash list hyb139-159-150-152:~/gitcode$ 另外恢复现场也可以采⽤ git stash apply 恢复但是恢复后stash内容并不删除你需要 ⽤ git stash drop 来删除 你可以多次stash恢复的时候先⽤ git stash list 查看然后恢复指定的stash⽤命令 git stash apply stash{0} ,这部分请同学们⾃⾏使⽤。 恢复完代码之后我们便可以继续完成开发开发完成后便可以进⾏提交 代码例如 hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d i am coding ... Done! hyb139-159-150-152:~/gitcode$ git add . hyb139-159-150-152:~/gitcode$ git commit -mmodify ReadMe [dev2 ed0916d] modify ReadMe 1 file changed, 1 insertion() 但我们注意到了修复 bug 的内容并没有在 dev2 上显⽰。 此时的状态图为 Master 分⽀⽬前最新的提交是要领先于新建 dev2 时基于的 master 分⽀的提交的所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。 我们的最终⽬的是要让 master 合并 dev2 分⽀的那么正常情况下我们切回 master 分⽀直接合并即可但这样其实是 有⼀定⻛险的。 是因为在合并分⽀时可能会有冲突⽽代码冲突需要我们⼿动解决在 master 上解决。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉因为在实际的项⽬中代码冲突不只⼀两⾏那么简单有可能⼏⼗上百⾏甚⾄更多解决的过程中难免⼿误出错导致错误的代码被合并到 master 上。 此时的状态图为 解决这个问题的⼀个好的建议就是 最好在⾃⼰的分⽀上合并下 master 再让 master 去合并dev 这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试⽽不影响 master 。 此时的状态图为 第一步 第二步 注意 对应的实操演⽰如下要说明的是以下演⽰的merge操作没有使⽤ --no-ff 但上述的图⽰是禁⽤ Fast forward 了模式后得出的主要是为了⽅便解释问题。 代码示例 # dev 合并 master hyb139-159-150-152:~/gitcode$ git branch * dev2 master hyb139-159-150-152:~/gitcode$ git merge master Auto-merging ReadMe CONFLICT (content): Merge conflict in ReadMe Automatic merge failed; fix conflicts and then commit the result. # 发⽣冲突 hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch HEAD a,b,c,d i am coding ... Done! a,b,c,d,e master # 解决冲突并重新提交 hyb139-159-150-152:~/gitcode$ vim ReadMe hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e i am coding ... Done! hyb139-159-150-152:~/gitcode$ git add . hyb139-159-150-152:~/gitcode$ git commit -mmerge master [dev2 447d29f] merge master hyb139-159-150-152:~/gitcode$ git status On branch dev2 nothing to commit, working tree clean # 切回master hyb139-159-150-152:~/gitcode$ git checkout master Switched to branch master # master 合并 dev2---⽆需解决冲突 hyb139-159-150-152:~/gitcode$ git merge dev2 Updating 193421f..447d29f Fast-forward ReadMe | 1 1 file changed, 1 insertion() hyb139-159-150-152:~/gitcode$ git status On branch master nothing to commit, working tree clean # 删除 dev2 分⽀ hyb139-159-150-152:~/gitcode$ git branch -d dev2 Deleted branch dev2 (was 447d29f). 三、删除临时分支 软件开发中总有⽆穷⽆尽的新的功能要不断添加进来。 添加⼀个新功能时你肯定不希望因为⼀些实验性质的代码把主分⽀搞乱了所以每添加⼀个新功能最好新建⼀个分⽀我们可以将其称之为 feature 分⽀在上⾯开发完成后合并最后删除该 feature 分⽀。 可是如果我们今天正在某个 feature 分⽀上开发了⼀半被产品经理突然叫停说是要停⽌新功能的开发。虽然⽩⼲了但是这个 feature 分⽀还是必须就地销毁留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。 演⽰如下 # 新增并切换到 dev3 分⽀ hyb139-159-150-152:~/gitcode$ git checkout -b dev3 Switched to a new branch dev3 # 开始开发新功能并提交 hyb139-159-150-152:~/gitcode$ vim ReadMe hyb139-159-150-152:~/gitcode$ cat ReadMe hello bit hello git hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e i am coding ... Done! i am writing new features ... hyb139-159-150-152:~/gitcode$ git add . hyb139-159-150-152:~/gitcode$ git commit -mmodify ReadMe for new features [dev3 cd2f149] modify ReadMe for new features 1 file changed, 1 insertion() # 此时新功能叫停 # 切回master准备删除dev3 hyb139-159-150-152:~/gitcode$ git checkout master Switched to branch master # 常规删除dev3分⽀时失败 hyb139-159-150-152:~/gitcode$ git branch -d dev3 error: The branch dev3 is not fully merged. If you are sure you want to delete it, run git branch -D dev3. 直接使⽤传统的删除分⽀的⽅法不⾏按照提⽰有了如下⽅式: 代码示例 hyb139-159-150-152:~/gitcode$ git branch -D dev3 Deleted branch dev3 (was cd2f149). hyb139-159-150-152:~/gitcode$ git branch * master 四、总结 gitee分支的作用 分⽀在实际中有什么⽤呢假设你准备开发⼀个新功能但是需要两周才能完成第⼀周你写了50%的代码如果⽴刻提交由于代码还没写完不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交⼜存在丢失每天进度的巨⼤⻛险。 现在有了分⽀就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀别⼈看不到还继续在原来的分⽀上。正常⼯作⽽你在⾃⼰的分⽀上⼲活想提交就提交直到开发完毕后再⼀次性合并到原来的分⽀上这样既安全⼜不影响别⼈⼯作。 并且 Git ⽆论创建、切换和删除分⽀Git在1秒钟之内就能完成⽆论你的版本库是1个⽂还是1万个⽂件。 总结
