网站的后期维护工作一般做什么,深圳建网站服务商,重庆集团公司网站建设,新时代文明实践站模板文章目录 创建与合并分支分支管理的概念实际操作 解决冲突分支管理策略Bug分支Feature分支多人协作 创建与合并分支
分支管理的概念
分支在实际中有什么用呢#xff1f;假设你准备开发一个新功能#xff0c;但是需要两周才能完成#xff0c;第一周你写了50%的代码#xf… 文章目录 创建与合并分支分支管理的概念实际操作 解决冲突分支管理策略Bug分支Feature分支多人协作 创建与合并分支
分支管理的概念
分支在实际中有什么用呢假设你准备开发一个新功能但是需要两周才能完成第一周你写了50%的代码如果立刻提交由于代码还没写完不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交又存在丢失每天进度的巨大风险。 现在有了分支就不用怕了。你创建了一个属于你自己的分支别人看不到还继续在原来的分支上正常工作而你在自己的分支上干活想提交就提交直到开发完毕后再一次性合并到原来的分支上这样既安全又不影响别人工作。
每次提交Git都把它们串成一条时间线这条时间线就是一个分支。截止到目前只有一条时间线在Git里这个分支叫主分支即master分支。HEAD严格来说不是指向提交而是指向mastermaster才是指向提交的所以HEAD指向的就是当前分支。
一开始的时候master分支是一条线Git用master指向最新的提交再用HEAD指向master就能确定当前分支以及当前分支的提交点
每次提交master分支都会向前移动一步这样随着你不断提交master分支的线也越来越长。
当我们创建新的分支例如dev时Git新建了一个指针叫dev指向master相同的提交再把HEAD指向dev就表示当前分支在dev上
你看Git创建一个分支很快因为除了增加一个dev指针改改HEAD的指向工作区的文件都没有任何变化
不过从现在开始对工作区的修改和提交就是针对dev分支了比如新提交一次后dev指针往前移动一步而master指针不变
假如我们在dev上的工作完成了就可以把dev合并到master上。Git怎么合并呢最简单的方法就是直接把master指向dev的当前提交就完成了合并
所以Git合并分支也很快就改改指针工作区内容也不变
合并完分支后甚至可以删除dev分支。删除dev分支就是把dev指针给删掉删掉后我们就剩下了一条master分支
实际操作
首先我们创建dev分支然后切换到dev分支 $ git checkout -b dev git checkout命令加上-b参数表示创建并切换相当于以下两条命令 $ git branch dev $ git checkout dev
然后用git branch命令查看当前分支 $ git branch git branch命令会列出所有分支当前分支前面会标一个*号。
然后我们就可以在dev分支上正常提交比如对test.txt做个修改加上一行 Creating a new branch is quick.
然后提交 $ git add test.txt $ git commit -m “branch test” 现在dev分支的工作完成我们就可以切换回master分支 $ git checkout master 切换回master分支后再查看一个test.txt文件刚才添加的内容不见了
因为那个提交是在dev分支上而master分支此刻的提交点并没有变 HEAD │ ▼ master │ ▼ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │───▶│ │───▶│ │───▶│ │ └───┘ └───┘ └───┘ └───┘ ▲ │ dev
现在我们把dev分支的工作成果合并到master分支上 $ git merge dev git merge命令用于合并指定分支到当前分支。合并后再查看readme.txt的内容就可以看到和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息Git告诉我们这次合并是“快进模式”也就是直接把master指向dev的当前提交所以合并速度非常快。 当然也不是每次合并都能Fast-forward我们后面会讲其他方式的合并。
合并完成后就可以放心地删除dev分支了 $ git branch -d dev
解决冲突
准备新的feature1分支继续我们的新分支开发 $ git switch -c feature1
修改test.txt最后一行改为 Creating a new branch is quick AND simple.
在feature1分支上提交 $ git add test.txt $ git commit -m “AND simple”
切换到master分支 $ git switch master
在master分支上把test.txt文件的最后一行改为 Creating a new branch is quick simple. 提交 $ git add test.txt $ git commit -m “ simple”
现在master分支和feature1分支各自都分别有新的提交变成了这样 这种情况下Git无法执行“快速合并”只能试图把各自的修改合并起来但这种合并就可能会有冲突我们试试看 $ git merge feature1
果然冲突了Git告诉我们test.txt文件存在冲突必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件 $ git status
我们可以直接查看readme.txt的内容 $ cat test.txt Git用标记出不同分支的内容
我们修改如下后保存 Creating a new branch is quick and simple. 再提交 $ git add test.txt $ git commit -m “conflict fixed”
现在master分支和feature1分支变成了下图所示 用带参数的git log也可以看到分支的合并情况 $ git log --graph --prettyoneline --abbrev-commit 问题 再次把两个分支合并的时候提示Already up to date. 因为你不能让一个最新的提交往回合并 解释 在master分支下修改并提交后此时master分支已经指向了修改后的新提交而feature分支仍指向发生冲突的那次提交。 在master分支下执行 git merge feature会提示“Already up to date.” 从内容上看master的提交内容要比feature新从时间轴上看master要晚于feature。 解决 $ git switch feature // 切换到feature分支 $ git merge master // 和master合并 合并成功此时无论你切换到哪个分支查看改文件的内容都是一样的。
小结 当Git无法自动合并分支时就必须首先解决冲突。解决冲突后再提交合并完成。 解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容再提交。 用git log --graph命令可以看到分支合并图。
当初将本地仓库推送到远程库时你应该是直接git push没有加-u本地和远程的分支没关联起来。 git push -u origin master “我们第一次推送master分支时加上了-u参数Git不但会把本地的master分支内容推送的远程新的master分支还会把本地的master分支和远程的master分支关联起来在以后的推送或者拉取时就可以简化命令。”
分支管理策略
通常合并分支时如果可能Git会用Fast forward模式但这种模式下删除分支后会丢掉分支信息。 如果要强制禁用Fast forward模式Git就会在merge时生成一个新的commit这样从分支历史上就可以看出分支信息。
下面我们实战一下–no-ff方式的git merge
首先仍然创建并切换dev分支 $ git switch -c dev Switched to a new branch ‘dev’ 修改readme.txt文件并提交一个新的commit $ git add readme.txt $ git commit -m “add China”
现在我们切换回master $ git switch master
准备合并dev分支请注意–no-ff参数表示禁用Fast forward 因为本次合并要创建一个新的commit所以加上-m参数把commit描述写进去 $ git merge --no-ff -m “merge with no-ff” dev
合并后我们用git log看看分支历史 $ git log --graph --prettyoneline --abbrev-commit
小结 在实际开发中我们应该按照几个基本原则进行分支管理 首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活 那在哪干活呢干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布时再把dev分支合并到master上在master分支发布1.0版本 你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了。
Bug分支
软件开发中有了bug就需要修复在Git中由于分支是如此的强大所以每个bug都可以通过一个新的临时分支来修复修复后合并分支然后将临时分支删除。
当你接到一个修复一个代号007的bug的任务时很自然地你想创建一个分支issue-007来修复它但是等等当前正在dev上进行的工作还没有提交 $ git status
并不是你不想提交而是工作只进行到一半还没法提交预计完成还需1天时间。但是必须在两个小时内修复该bug怎么办 幸好Git还提供了一个stash功能可以把当前工作现场“储藏”起来等以后恢复现场后继续工作 $ git stash
现在用git status查看工作区就是干净的除非有没有被Git管理的文件因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug假定需要在master分支上修复就从master创建临时分支 $ git checkout master $ git checkout -b issue-007
现在修复bug需要把“Git is free software …”改为“Git is a free software …”然后提交 $ git add readme.txt $ git commit -m “fix bug 007”
修复完成后切换到master分支并完成合并最后删除issue-007分支 $ git switch master $ git merge --no-ff -m “merged bug fix 007” issue-007
现在是时候接着回到dev分支干活了 $ git switch dev $ git status
工作区是干净的刚才的工作现场存到哪去了用git stash list命令看看 $ git stash list
工作现场还在Git把stash内容存在某个地方了但是需要恢复一下有两个办法 一是用git stash apply恢复但是恢复后stash内容并不删除你需要用git stash drop来删除 另一种方式是用git stash pop恢复的同时把stash内容也删了 $ git stash pop
恢复的时候先用git stash list查看然后恢复指定的stash用命令 $ git stash apply stash{0} 删除用 $ git stash drop stash{0}
发散思维 在master分支上修复了bug后我们要想一想dev分支是早期从master分支分出来的所以这个bug其实在当前dev分支上也存在。 那怎么在dev分支上修复同样的bug重复操作一次提交不就行了 有木有更简单的方法 有 同样的bug要在dev上修复我们只需要把5560e30 fix bug 007这个提交所做的修改“复制”到dev分支。注意我们只想复制5560e30 fix bug 007这个提交所做的修改并不是把整个master分支merge过来。 为了方便操作Git专门提供了一个cherry-pick命令让我们能复制一个特定的提交到当前分支 $ git branch $ git cherry-pick 5560e30
既然可以在master分支上修复bug后在dev分支上可以“重放”这个修复过程那么直接在dev分支上修复bug然后在master分支上“重放”行不行当然可以不过你仍然需要git stash命令保存现场才能从dev分支切换到master分支。
Feature分支
软件开发中总有无穷无尽的新的功能要不断添加进来。 添加一个新功能时你肯定不希望因为一些实验性质的代码把主分支搞乱了所以每添加一个新功能最好新建一个feature分支在上面开发完成后合并最后删除该feature分支。 现在你终于接到了一个新任务开发代号为Vulcan的新功能该功能计划用于下一代星际飞船。
于是准备开发 $ git switch -c feature-vulcan
5分钟后开发完毕 $ git add vulcan.py $ git status
切回dev准备合并 $ git switch dev
一切顺利的话feature分支和bug分支是类似的合并然后删除。
但是 就在此时接到上级命令因经费不足新功能必须取消 虽然白干了但是这个包含机密资料的分支还是必须就地销毁 $ git branch -d feature-vulcan 此时会error: The branch ‘feature-vulcan’ is not fully merged. If you are sure you want to delete it, run ‘git branch -D feature-vulcan’. 销毁失败。Git友情提醒feature-vulcan分支还没有被合并如果删除将丢失掉修改如果要强行删除需要使用大写的-D参数。 我们要强行删除 $ git branch -D feature-vulcan
多人协作
多人协作 当你从远程仓库克隆时实际上Git自动把本地的master分支和远程的master分支对应起来了并且远程仓库的默认名称是origin。
要查看远程库的信息用git remote $ git remote 用git remote -v可以显示更详细的信息 $ git remote -v 上面显示了可以抓取和推送的origin的地址。如果没有推送权限就看不到push的地址。
推送分支 推送分支就是把该分支上的所有本地提交推送到远程库。推送时要指定本地分支这样Git就会把该分支推送到远程库对应的远程分支上 $ git push origin master 如果要推送其他分支比如dev就改成 $ git push origin dev 但是并不是一定要把本地分支往远程推送那么哪些分支需要推送哪些不需要呢 master分支是主分支因此要时刻与远程同步
dev分支是开发分支团队所有成员都需要在上面工作所以也需要与远程同步
bug分支只用于在本地修复bug就没必要推到远程了除非老板要看看你每周到底修复了几个bug
feature分支是否推到远程取决于你是否和你的小伙伴合作在上面开发。
抓取分支 多人协作时大家都会往master和dev分支上推送各自的修改。
现在模拟一个你的小伙伴可以在另一台电脑注意要把SSH Key添加到GitHub或者同一台电脑的另一个目录下克隆 $ git clone gitgithub.com:songwaimaideyasuo/learngit.git 当你的小伙伴从远程库clone时默认情况下你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看 $ git branch
现在你的小伙伴要在dev分支上开发就必须创建远程origin的dev分支到本地于是他用这个命令创建本地dev分支 $ git checkout -b dev origin/dev
现在他就可以在dev上继续修改然后时不时地把dev分支push到远程 $ git add env.txt $ git commit -m “add env” $ git push origin dev
你的小伙伴已经向origin/dev分支推送了他的提交而碰巧你也对同样的文件作了修改并试图推送 $ git add env.txt $ git commit -m “add new env” $ git push origin dev 推送失败因为你的小伙伴的最新提交和你试图推送的提交有冲突解决办法也很简单Git已经提示我们先用git pull把最新的提交从origin/dev抓下来然后在本地合并解决冲突再推送 $ git pull git pull也失败了原因是没有指定本地dev分支与远程origin/dev分支的链接根据提示设置dev和origin/dev的链接 $ git branch --set-upstream-toorigin/dev dev
再pull $ git pull
这回git pull成功但是合并有冲突需要手动解决解决的方法和分支管理中的解决冲突完全一样。解决后提交再push $ git add env.txt $ git commit -m “fix env conflict” $ git push origin dev
小结 因此多人协作的工作模式通常是这样 首先可以试图用$ git push origin 推送自己的修改 如果推送失败则因为远程分支比你的本地更新需要先用$ git pull试图合并 如果合并有冲突则解决冲突并在本地提交 没有冲突或者解决掉冲突后再用$ git push origin 推送就能成功 如果git pull提示no tracking information则说明本地分支和远程分支的链接关系没有创建用命令$ git branch --set-upstream-to origin/。 这就是多人协作的工作模式一旦熟悉了就非常简单。
查看远程库信息使用$ git remote -v 本地新建的分支如果不推送到远程对其他人就是不可见的 从本地推送分支使用$ git push origin branch-name如果推送失败先用git pull抓取远程的新提交 在本地创建和远程分支对应的分支使用$ git checkout -b branch-name origin/branch-name本地和远程分支的名称最好一致 建立本地分支和远程分支的关联使用$ git branch --set-upstream branch-name origin/branch-name 从远程抓取分支使用git pull如果有冲突要先处理冲突。
