不知道有没有人玩过
在第四关的git rebase 中我有一些疑问，不知道大家能否解答
从c1尝试分支bugFix后再提交得到c2（上面这是已经经过提交的图片，具体的可以去playground里试试）
将c2 rebase到master上
看着没问题，但是如果bugFix分支上代码与master有冲突的话怎么办，我想不明白， 不知道你们是怎么解决的
看着没问题，但是如果bugFix分支上代码与master有冲突的话怎么办，我想不明白， 不知道你们是怎么解决的
rebase 和 merge 一样，都是需要解决冲突的。
对啊，我想看看你们是怎么做的
什么叫“你们怎么做？” 难道不是有冲突，就解决冲突，然后 continue rebase 么？
比如说一个文件readme有bug, 然后在其他分支上改bug,
改好以后与主分支合并，可能有冲突，那么我创建分支还有必要吗，直接在maser上改不就好了
我是这样想的
我理解，你考虑的这个情况和rebase/merge 有冲突怎么解决 是两个问题。你是考虑什么时候你需要用rebase/merge ？
我现在还不会在多个分支下，所以我不太明白你的意思， 可以举一些例子吗，比如说？？
我有这样的一个场景： 我用spacemacs 的develop 分支，我想跟进这个分支的同时，在上面进行非常小量的修改，以匹配我的场景。
我这么处理，
- fork spacemacs repo；
- 在forked repo上 develop分支 保持一致和spacemacs develop分支同步
- 在forked repo develop基础上，checkout 一个新的分支，比如mine
- 实际中，我应用的分支是mine； 在remote spacemacs develop 分支更新时，我会在我的forked develop分支，直接进行pull，来保证和远程同步； 然后checkout 到mine分支上，做rebase develop (我forked的repo)。
我在这里做rebase而不是merge，是希望我的mine分支看起来，也是线性在develop分支上面做添加， 做merge 也可以，但这样这个branch history看起来会有点杂乱。 在rebase的过程， 有可能出现conflict，需要解决。
我有点理解了，但你这个mine和dev分支可能就在一条直线上，rebase或merge可能就是把mine指向最前面的dev啊
其实我还是想不明白，他们创立bugFix分支，然后在这个分支上提交一堆东西，最后等版本稳定下来后与master合并，我不明白他们如何应对原地修改文件的这种情况
你说的原地修改是什么意思？是master分支有变化，还是其他？
像刚才说的，原地修改出bug的readme文件，然后合并
先不要想合并，先想想你怎么提交？
在一个实际多人开发一个repo的场景中，你的分支你开发了1个月，这时候你觉得可以通过PR 让管理者merge到master 分支，但这一个月master分支和你当时checkout时已经有很多commits了。
你直接提交PR 还不够，你还需要将这一个月的更新先rebase到你的分支，使得你的修改看似是在最新的master commit上进行的添加，然后再发送PR。
这个时候，项目管理者在master分支merge你的PR， 就会变得比较自然方便，review你的代码也会比较方便。
PR好像只出现在多人合作的场景，也就是说，网络上的托管平台，如github 我平时都是一个人开发，这个PR是git提供的功能还是托管平台提供的功能
感觉完全是鸡同鸭讲。。。
develop分支是为了和上游保持一致，mine是在develop分支基础上修改而来的自己的配置，如果你直接在develop分支上修改，就无法直接从上游拉取更新。
举个例子，你开发了一个软件，master分支就是你认为可以稳定运行的版本；develop分支是你往里加了新内容的版本，因为加了新内容不可避免的会有些bug，为了别人能正常使用，你必须在develop上测试符合预期后再合并到master分支；而bugfix就好比大多数人都用的好好的，但是有人测试出了一个bug，因为是在稳定运行的版本上出现的，你为了解决他的问题在master而不是develop上新开了一个bugfix分支，而解决问题自然也要修修改改，很多时候是不能一蹴而就的，为了不影响大多数人的正常使用，新分支就很有必要了。
至于你所说的直接修改，都直接修改了为什么还要再合并。。。
请原谅我学艺不精，我想的完全是本地的分支
这些东西你实际用一下就明白怎么回事了，日常使用的都是很简单的，复杂的交给专家来干，谈来谈去只会徒增问题的复杂度。
你说的这个问题根本就不是对立的关系，master是你可以稳定使用的，dev是你用来添加新功能的分支，dev上测试正常，自然要合并到master分支
你是还没明白dev分支所起的作用
版本迭代必然要对原有代码进行扬弃，你直接在master分支上修改，也一定是对代码删删改改
dev分支是把你原本要在master分支上做的修改转移到了dev分支上，保证master分支的代码是始终能正常运行的