暗色系网站,长春网站建设58同城,dedecms网站后台模板,前端微信小程序开发目录 理解分支
创建分支
切换分支
合并分支
删除分支
合并冲突
分支管理策略
快进合并
正常合并
bug 分支 总结 理解分支 在版本控制系统中#xff0c;分支是一条独立的开发线路。它允许开发者从一个主要的代码基线#xff08;例如master分支#xff09;分离出来…目录 理解分支
创建分支
切换分支
合并分支
删除分支
合并冲突
分支管理策略
快进合并
正常合并
bug 分支 总结 理解分支 在版本控制系统中分支是一条独立的开发线路。它允许开发者从一个主要的代码基线例如master分支分离出来进行独立的开发工作如开发新功能、修复漏洞等而不会影响主分支的稳定性。 在版本回退里我们已经知道每次提交Git都把它们串成⼀条时间线这条时间线就可以理解为是⼀个分支。截至到目前只有一条时间线在Git里这个分支叫主分支即 master 分支。 再来理解⼀下HEADHEAD 严格来说不是指向提交而是指向 mastermaster才是指向提交的所以HEAD 指向的就是当前分支。 创建分支
查看本地仓库中的所有分支当前所在的分支会在列表中以 * 符号标记出来。 git branch 创建一个新的分支
方法一
git branch 新分支名方法二
git checkout -b 新分支名
创建完成分支后会自动切换过去
方法一 方法二 切换分支
git checkout 切换的分支名 合并分支
将一个或多个分支的修改合并到当前分支
git merge 要合并的分支 我们来做一个简单的小实验 在目录下创建一个文件test 并且输入一行内容切换到 dev 分支下在 dev 分支下修改 test 文件新增一行内容并进行一次提交操作对比master分支 和 dev 分支 test 文件内容的区别
我们在目录下创建一个文件test 并且输入一行内容 我们切换到 dev 分支下 在 dev 分支下修改 test ⽂件新增一行内容并进行一次提交操作 对比master分支 和 dev 分支 test 文件内容的区别 总结在 master 分支上内容没有添加在 dev 分支上内容添加了。为什么会出现这个现象呢我们来看看 dev 分支和 master 分支指向发现两者指向的提交是不⼀样的
看到这里就能明白了因为我们是在dev 分支上提交的而master 分支此刻的提交点并没有变此时的状态如图如下 为了在 master 主分支能看到新的提交就需要将 dev 分支合并到 master 分支 合并后master 分支就能看到 dev 分支提交的内容了。此时的状态如图如下所示 删除分支
删除本地分支已经合并过的分支
git branch -d 要删除的分支名 强制删除本地分支未合并的分支
git branch -D 要删除的分支名 有些时候我们开发一个分支开发到一半还没有合并如果这个时候我们不想要了我们想要删除分支就得强制删除本地分支 合并冲突 在实际分支合并的时候并不是想合并就能合并成功的有时候可能会遇到代码冲突的问题。 我们来做一个简单的小实验 创建⼀个新的分支 dev 并切换至dev 分支 在 dev 分支 下修改 test ⽂件更改文件内容并提交 切换到 master 分支 观察 test 文件内容对 test 文件再进行一次修改并提交 master 分支 和 dev分支 进行合并
创建⼀个新的分支 dev 并切换至dev 分支 在 dev 分支下修改 test ⽂件更改文件内容并提交 切换到 master 分支观察 test 文件内容对 test 文件再进行一次修改并提交 master 分支 和 dev分支 进行合并这种情况下Git 只能试图把各自的修改合并起来但这种合并就可能会有冲突 发现 test 文件有冲突后可以直接查看文件内容要说的是 Git 会用 来标记出不同分支的冲突内容如下所示 此时我们必须要手动调整冲突代码并需要再次提交修正后的结果 到这里冲突就解决完成此时的状态变成了 分支管理策略
查看提交历史的命令类图形化查看提交历史
git log --graph --prettyoneline --abbrev-commit 我们有两种分支合并的方法我们应该如何去选择呢
快进合并Fast - forward Merge正常合并Three - way Merge
快进合并
适用场景和条件这种合并适用于源分支是目标分支的直接后继并且源分支上的所有提交都是在目标分支最新提交的基础上线性进行的情况。例如从master分支创建new - feature分支后master分支没有新的修改而new - feature分支进行了一系列的提交。 在 Fast - forward Merge 模式下删除分支后查看分支历史时会丢掉分支信息看不出来最新提交到底是 merge 进来的还是正常提交的 正常合并
适用场景和条件当目标分支和源分支有独立的提交历史即从它们的共同祖先之后有各自的修改时需要进行正常合并。例如master分支和feature - branch都有从共同祖先之后的新提交。 在 Three - way Merge模式下 这样的好处是从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev 分支 但依旧能看到 master 其实是由其他分支合并得到 我们可以强制禁用 快进合并 模式那么就会在 merge 时⽣成⼀个新的 commit 这样从分支历史上就可以看出分支信息。
git merge --no-ff -m 提交文件的描述 合并的分支名
不使用 快进合并模式合并后就像这样 所以在合并分支时加上 --no-ff 参数就可以用普通模式合并合并后的历史有分支能看出来曾 经做过合并而 fast forward 合并就看不出来曾经做过合并 在实际开发中我们应该按照几个基本原则进行分支管理 master 分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活干活都在dev 分支上也就是说dev 分支是不稳定的到某个时候⽐如1.0版本发布时再把dev 分支合并到 master 分支上在master 分支发布1.0版本我们每个人都在dev 分支上干活每个人都有自己的分支时不时地往dev 分支上合并就可以了。 所以团队合作的分支看起来就像这样 bug 分支
假如我们现在正在 dev2 分支上进行开发开发到⼀半突然发现 master 分支之上面有 bug需要解决每个 bug 都可以通过⼀个新的临时分支来修复修复后合并分支然后将临时分支删除可现在 dev2 的代码在工作区中开发了⼀半还无法提交怎么办
暂时保存当前工作目录的修改这些修改可以是未提交的文件修改、新添加的文件或者暂存区stage area中的修改。它允许你在不提交当前工作的情况下切换分支或者处理其他紧急任务之后再回来恢复这些修改继续工作。
git stash
查看所有已保存的stash暂存记录的列表。当你使用git stash命令保存工作目录和暂存区的修改时这些修改会被存储在一个栈结构中git stash list命令就是用来查看这个栈中所有记录的详细信息的。
git stash list
用于恢复并删除git stash栈顶最新保存的修改记录的命令。它结合了git stash apply应用暂存的修改和git stash drop删除暂存的修改的功能。
git stash pop // apply dropgit stash apply // 恢复工作区的内容
git stash drop // 删除暂存的修改
但我们注意到了修复 bug 的内容并没有在 dev2 上显示。此时的状态图为 master 分支目前最新的提交是要领先于新建 dev2 时基于的 master 分支的提交的所以我们在 dev2 中当然看不见修复 bug 的相关代码我们的最终目的是要让 master 合并 dev2 分支的那么正常情况下我们切回 master 分支直接合并即可但这样其实是有⼀定风险的是因为在合并分支时可能会有冲突而代码冲突需要我们手动解决在 master 上解决。我们无法保证对于冲突问题可以正确地⼀次性解决掉因为在实际的项目中代码冲突不只⼀两行那么简单 有可能几十上百行甚至更多解决的过程中难免手误出错导致错误的代码被合并到 master 上。 解决这个问题的⼀个好的建议就是最好在自己的分支上合并下 master 再让 master 去合并dev2 这样做的目的是有冲突可以在本地分支解决并进行测试而不影响 master 。
此时的状态为 总结 分支在实际中有什么用呢 假设你准备开发⼀个新功能但是需要两周才能完成第⼀周你写了50% 的代码如果立刻提交由于代码还没写完不完整的代码库会导致别人不能干活了。如果等代码全部写完再⼀次提交又存在丢失每天进度的巨大风险。 现在有了分支就不用怕了。你创建了⼀个属于你自己的分支别人看不到还继续在原来的分支上正常⼯作而你在自己的分支上干活想提交就提交直到开发完毕后再一次性合并到原来的分支上这样既安全又不影响别人工作。 并且 Git 无论创建、切换和删除分支Git在1秒钟之内就能完成无论你的版本库是1个文件还是1万个文件。
