标签 Git 下的文章 - “青年博客”

2019-01-09

Git学习(第八天) Feature分支:通常添加一个新功能，我们可定不希望因为一些实验性的代码而把分支搞乱，所以每添加一个功能最好是建一个feature分支，在feature分支上面开发、实验，完成后根据需要进行合并，最后删除该featrue分支。下面，举例一个场景：在工作中，当我们接到一个新的功能，该功能计划于下一个开发版本中。开始准备开发。1、创建分支$git checkout -b feature-car2、快速的开发完毕，提交代码$git add NewCarController.java $git commit -m '新车辆档案' 3、切回dev，合并到dev分支上$git checkout dev在这里的合并和其他分支的合并、删除是一样的。就在合并的此时，接到了上级的命令，因为合同问题，该功能被砍掉不需要了。这个分支也包含了一些比较重要的代码，既然不需要了还是需要就地销毁的4、删除feature分支$git branch -d feature-car error: The branch 'feature-car' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-car'.咦？提示删除失败报错了？还好Git友情提示，feature-car分支还没有被合并，如果删除将丢失掉该分支的所有修改，如果要强行删除，需要使用大写的-D参数。好了，现在我们强行删除$git branch -D featrue-car总结：开发一个新的功能，最好是新建一个分支，如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。多人协作:从远处仓库克隆时，实际上git自动将本地的master分支与远程的master分支对应起来了，并且远程仓库的默认名是origin。查看远程仓库信息使用git remote 或用查看信息更详细的 git remote -v$ git remote GitGo $ git remote -v GitGo git@git.oschina.net:Mr.bai/GitGo.git (fetch) GitGo git@git.oschina.net:Mr.bai/GitGo.git (push) 上面显示的抓取和推送的地址，没有推送权限的就看不到push地址。推送分支把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上$ git push GitGo master如果要推送其他分支$ git push GitGo dev当然，也并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，根据你的需要而定。抓取分支在多人协作开发时，大家都会往master和dev分支上推送各自的修改。当我们从远程库克隆一个项目，默认情况下只能看到本地的master。可以使用git bransh查看。然后现在你的小伙伴需要在dev分支上开发，就必须创建远程的origin和dev分支到本地，于是他用git checkout -b dev origin/dev 命令创建本地dev分支，他就可以在dev上继续修改，然后时不时的把dev分支push到远程。$ git add test.txt $ git commit -m 'add Test.txt' $ git push origin dev 你的小伙伴向origin/dev分支推送了他的提交，而碰巧你也对同样的文件做了修改，并试图推送$ git add test.txt $ git commit -m 'add test.txt' $ git push origin dev Togithub.com:KerryPak/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:KerryPak/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送$ git pull There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> dev git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接$ git branch --set-upstream-to=origin/dev dev Branch 'dev' set up to track remote branch 'dev' from 'origin'. 再pull$ git pull Auto-merging test.txt CONFLICT (add/add): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result. 这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push$ git commit -m "fix test conflict" [dev 57c53ab] fix test conflict $ git push origin dev Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git 7a5e5dd..57c53ab dev -> dev 因此，多人协作的工作模式通常是这样：1、首先，可以试图用git push origin <branch-name>推送自己的修改；2、如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；3、如果合并有冲突，则解决冲突，并在本地提交；4、没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。这就是多人协作的工作模式，一旦熟悉了，就非常简单。小结：1、查看远程库信息，使用git remote -v；2、本地新建的分支如果不推送到远程，对其他人就是不可见的；3、从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；4、在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；5、建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；6、从远程抓取分支，使用git pull，如果有冲突，要先处理冲突Rebase在版本库中，经过我们一次次的合并push之后，分子就变成了下面这个样子$ git log --graph --pretty=oneline --abbrev-commit * d1be385 (HEAD -> master, origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed 对于有强迫症的人来说可能会看起来很乱。Git有一种称为rebase的操作，有人把它翻译成“变基”，将分支中的所有提交(commit)合并都调整合并(应用)在分支的基线上。想让分支历史看起来像没有经过任何合并一样，你也许可以用 git rebase$ git checkout dev $ git rebase origin这些命令会把你的"dev"分支里的每个提交(commit)取消掉，并且把它们临时保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新为最新的"origin"分支，最后把保存的这些补丁应用到"dev"分支上。《rebase 前》《rebase 中》当'dev'分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. （请查看 git gc)《rebase 后》好了，我们现在再次查看一下git log$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 * d1be385 init hello ... 这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。最后，通过push操作把本地分支推送到远程$ git push origin master 远程分支的提交历史现在也是一条直线啦。在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:$ git rebase --continue 这样git会继续应用(apply)余下的补丁。在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。$ git rebase --abort 小结：1、rebase操作可以把本地未push的分叉提交历史整理成直线；2、rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

2019年01月09日
318 阅读
0 评论
0 点赞

2018-11-25

Git学习(第七天) 我们在合并分支时，Git会用到”Fast forward“模式，在这种模式下删除分支后会丢掉分支信息。如果我们要强制禁用”Fast forward“模式，Git就会在merge时生存一个新的commit，这样从分支历史上就可以看出分支信息。那么，如何强制禁用”Fast forward“模式呢？在merge时加上参数 --no-ff 即可。创建并切换一个分支dev：$ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件并提交：$ git add readme.txt $ git commit -m '修改readme' [dev c835981] 修改readme 1 file changed, 1 insertion(+) 提交完成后切换至master：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 7 commits. (use "git push" to publish your local commits) 现在开始合并dev分支到master，在使用merge时使用--no-ff禁用”Fast forward“：$ git merge --no-ff -m '禁用fast forward方式合并文件' dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 因为本次禁用了”Fast forward“合并会创建一个新的commit，所以在后面加上了-m参数，把commit描述写进去。合并后可以使用git log查看分支历史：$ git log --graph --pretty=oneline --abbrev-commit * 068ed5b (HEAD -> master) 禁用fast forward方式合并文件 |\ | * c835981 (dev) 修改readme |/ * da26543 修改文件内容 |\ | * cfc178e 修改Git为git * | 898bd79 修改文字为繁体字，修改标点符号为英文 |/ * e235cf1 一个新的版本 * 081fd0d 修改后的文件 |\ | * 3b0631c 分支冲突解决学习1 * | 607fe21 修改的今天修改的内容【学习分支冲突解决方法】 |/ * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件；修改项目说明文件； * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 可以从上面的操作历史中看到，不使用"Fast forward"模式，merge后就像这样：分支策略：通常在实际的开发中，我们应该按照几个基本原则进行分支管理：首先，master分⽀应该是非常稳定的，也就是仅用来发布新版本，平时不能在上⾯干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分⽀是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以，团队合作的分⽀支看起来就像这样：小结Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。BUG分支：软件开发中，产生BUG几乎是我们每天无法避免的一件事。当然，既然有了BUG那就需要修复。比如现有一个BUG需要马上进行修复处理。这个时候，就可以体现出Git中强大的分支管理了。我们可以通过一个临时分支来修复BUG，修复后合并分支，然后将临时分支删除。但接到一个修复的BUG任务，很自然地想到创建一个分支issue-105来修复他，但是我们当前正在dev上进行着开发工作，这部分代码还没有提交：$ git status On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt 由于我的功能开发到一半，预计开发完成至少还需要1天，很显然这个未完成的代码是不能提交的。但是目前必须需要在最短的时间内修复这个BUG，怎么办？强大的Git为我们提供了一个stash功能，可以把当前的工作现场”储藏“起来，等以后恢复现场继续工作：$ git stash Saved working directory and index state WIP on dev: c835981 修改readme 现在用git status查看工作区：$ git status On branch dev nothing to commit, working tree clean目前工作区是干净的（除还没有被Git管理的文件），因此可以放心的创建分支来修复Bug。首先得确认修复BUG是在那个分支上。假设我们需要在master上修复该BUG，就在master上创建临时的分支：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git checkout -b issue-105 Switched to a new branch 'issue-105' 修改文件然后提交：$ git add test.txt $ git commit -m '修改BUG' [issue-105 05372b9] 修改BUG 1 file changed, 1 insertion(+), 1 deletion(-) 提交完成后，切换到master分支，合并issue-105分支，合并完成后删除issue-105分支：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m '修复BUG105' issue-105 Merge made by the 'recursive' strategy. test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-105 Deleted branch issue-105 (was 05372b9). 好的。BUG105我们已经修复并提交了master了。现在我们需要返回dev继续干刚才没有完成的活。$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean 工作区我们刚刚在dev修改的文件，哪去了？不要着急。用git stash list 命令查看：$ git stash list stash@{0}: WIP on dev: c835981 修改readmedev的工作现场还在，Git只是把stash内容存放在某个地方了，但是需要恢复一下，有两个方法：1、使用git stash apply 恢复，但是在恢复后，stash内容并没有删除，需要使用git stash drop 来删除；$ git stash apply On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop Dropped refs/stash@{0} (190f697d730a4a7816b3049acf7cf33d6d162162) 2、使用git stash pop，恢复的同时把stash内容也删除了：$ git stash pop On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (62947f8efd82d5b72410cdabd47eaaffa4d53dca) 再用git stash list查看，就看不到任何的stash内容：$ git stash list可以多次stash，恢复的时候先用git stash list查看队列，然后恢复时指定stash序列；stash的队列是按照的时间的先后顺序倒叙排列的（即时间最新的在前，stash@{0}）;存在多个stash在不指明恢复序列，默认为队列第一个。$ git stash list stash@{0}: WIP on dev: c835981 修改readme stash@{1}: WIP on dev: c835981 修改readme stash@{2}: WIP on dev: c835981 修改readme $ git stash apply stash@{1} On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop stash@{1} Dropped refs/stash@{1} (159798b0499e0acf7cf33d6d162162a5fff64f0d) 修改BUG时，我们会通过创建新的BUG分支进行修复，然后合并，最后删除；当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复完成后，再git stash pop，重新回到工作现场。

2018年11月25日
224 阅读
0 评论
0 点赞

2018-11-13

Git学习(第六天) 在项目中，通常会发生多个人对一个文件进行修改，这样在合并分支的时候就很难避免不发生冲突。一旦在我们合并的时候出现冲突，这个时候我们该怎么解决呢？下面以一个例子来演示冲突如何解决：准备一个新的分支：featrue1，继续在新的分支开发：$ git checkout -b feature1 Switched to a new branch 'feature1' 查看当前的工作区指向的是哪个分支：$ git branch * feature1 master 接下来，修改feature1分支中的readme.txt：feature1分支中的readme.txt原来的内容：”Git学习：解决冲突。"（如上图）修改为：”git学习：解决冲突。"(如下图)修改完成后在feature1分支上提交：$ git add readme.txt $ git commit -m '修改Git为git' [feature1 cfc178e] 修改Git为git 1 file changed, 1 insertion(+), 1 deletion(-) 切换到master分支上：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 1 commits. (use "git push" to publish your local commits) Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。在master分支上把readme.txt文件的内容进行修改：master分支中的readme.txt原来的内容：”Git学习：解决冲突。"（如上图）修改为：”Git学習:解决冲突."(如下图)在master分支上提交readme.txt文件：$ git add readme.txt $ git commit -m '修改文字为繁体字，修改标点符号为英文' [master 898bd79] 修改文字为繁体字，修改标点符号为英文 1 file changed, 1 insertion(+), 1 deletion(-) 好了，现在master分支和feature1分支各自都分别有新的提交了：这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. 果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：$ git status On branch master Your branch is ahead of 'GitGo/master' by 5 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") 现在直接查看readme.txt的内容：Git 用<<<<<<<，=======，>>>>>>> 标记出不同分支的内容，我们修改如下后保存：再提交：$ git add readme.txt $ git commit -m '修改文件内容' [master da26543] 修改文件内容现在，master分支和feature1分支变成了下图所示：用带参数的git log也可以看到分支的合并情况：$ git log --graph --pretty=oneline --abbrev-commit * da26543 (HEAD -> master) 修改文件内容 |\ | * cfc178e (feature1) 修改Git为git * | 898bd79 修改文字为繁体字，修改标点符号为英文 |/ * e235cf1 一个新的版本 * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件；修改项目说明文件； * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 当我们合并分支解决完冲突之后，删除feature1分支：$ git branch -d feature1 Deleted branch feature1 (was cfc178e). OK，到这里为止，在进行分支合并中出现的冲突就算是解决完成了。总结：1、当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。2、解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。3、用git log --graph命令可以看到分支合并图。

2018年11月13日
198 阅读
0 评论
0 点赞

2018-09-14

git如何将本地仓库推送到远程仓库上当我们本地仓库的项目开发完成需要将本地仓库内容推送到远程仓库上去，这个时候该如何操作呢？1、先需要将本地仓库关联到远程库：git remote add origin <url>。如：$ git remote add origin git@gitee.com:Mr.bai/Flyway_demo.git2、获取远程仓库并将其与本地仓库进行合并（如果远程库不为空必须做这一步，否则后面的提交会失败）$ git pull –rebase origin master把本地仓库的内容推送到远程，使用git push 命令。实际上是把当前分支master推送到远程。执行此命令后会要求输入用户名、密码，验证通过后即开始上传。$ git push -u origin master或$ git push

2018年09月14日
214 阅读
2 评论
0 点赞

2018-09-14

2018年09月14日
179 阅读
0 评论
0 点赞

2018-06-29

Git学习(第五天) Git分支管理分支就是美国科幻大片里面的平行空间，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。两个平行空间互不干扰。但是在某个时间，两个空间合并了。然后你就学会的两个技能Git和SVN。分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。首先，需要了解Git分支内部是怎么运作的。在版本回退中，每次提交Git都它们串成一条时间线，这条时间就是一个分支，这个分支叫主分支master。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：每次提交，master分支都会向前移动异步，这样，随着你不断提交，master分支的线也越来越长。当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向就表示当前分支在dev上：你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化。不过，从现在开始，对工作区的修改和提交就是针对dev分支了。比如新提交一次后，dev指针往前移动一步，而master指针不变：假如我们在dev上工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：所以Git合并分支也很快~ 就改改指针，工作区内容也不变~合并完成支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删除，删掉后，我们就剩下了一条master分支：真实太神奇了，你看的出来有些提交时通过分支完成的吗？下面开始实战。首先，我们创建dev分支，然后切换到dev分支：$ git checkout -b dev Switched to a new branch 'dev'git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：$ git branch dev $ git checkout dev Switched to branch 'dev'然后，用git branch命令查看当前分支：$ git branch * dev mastergit branch命令会列出所有分支，当前分支前面会标一个*号。然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：Creating a new branch is quick.然后提交：$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+)现在，dev分支的工作完成，我们就可以切换回master分支：$ git checkout master Switched to branch 'master'切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：现在，我们把dev分支的工作成果合并到master分支上：$ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。合并完成后，就可以放心地删除dev分支了：$ git branch -d dev Deleted branch dev (was fec145a). 删除后，查看branch，就只剩下master分支了： $ git branch * master因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。命令总结：在Git中鼓励大量使用分支：查看分支：git branch创建分支：git branch <name>切换分支：git checkout <name>创建+切换分支：git checkout -b <name>合并某分支到当前分支：git merge <name>删除分支：git branch -d <name>

2018年06月29日
193 阅读
1 评论
0 点赞