我知道这个意思，有可能我还是没讲明白
不过谢谢提醒
要我感觉的话，你的疑惑主要就在于没用过，所以有这种问题 
如果是用 git 管理自己私人的配置，有没有分支都无所谓，毕竟修改很频繁，也不需要考虑别人使用这个有没有问题
但是跟别人合作搞一个项目，我的做法是有一个upstream分支与上游保持一致，master分支保证与upstream分支一致，然后针对不同的工作在master上新建不同的分支，到时候提交pr也方便些
假设 master 分支 c1 为你克隆的 spacemacs develop 分支， c4 是在你克隆之后他人提交的代码， c2 和 c3 是你对 c1 的修改。当你打算将 c3 提交到 spacemacs 。为了保证你提交的 pr 可以和 spacemacs 没有冲突，你难道不应该在 master 分支 c1 之上拉取 c4 吗？ 之后将 c3 和 c4 的代码合并 到 master c5 吗？ 至于产生的冲突，一般会在冲突文件中展示出来，你可以根据提示手动修改的。
PS： 除非你修改的部分和他人提交的部分无关，一定会产生冲突的。
具体实施可以参考：
我觉得我的表述太容易混淆了
我重新整理一下，我是对这个教程尝试的分支节点有疑问，我的假设场景是
如果我只对一个readme文件进行版本控制，在提交过程中一直稳定，直到在c1节点发现bug，在此节点创立分支dev，并提交
不过这时我一个手贱在master上提交了一次，
那么这个教程第四关操作过后得到正确答案还能被用来参考做git rebase的例子吗？
ps: 上面有个灰色的c2，他也是节点 ps的ps: 不要在意前两个图片和最后一个图片的提交有区别，前两个我只是举个不准确的例子
- 问题表述清晰是理解事物的关键一步；你的问题始终含糊不清，夹杂了如如何做rebase，什么时候做rebase, 为什么要做rebase, 怎么参考案例做rebase等。
- 与其这么问，不如你自己动手创建你的case，自己尝试在project上做rebase 或者simulate你的疑惑，自己来解决。你考虑的情景比较简单，也很容易模拟，为什么不自己动手玩一玩，老是盯着网上这个教程有啥用。
感觉你太纠结于这个所谓 教程 了，不如你自己去 github 建一个 repo，提交一下，rebase 一下体验一下。
至于你这个图，在 Master 的提交，不应该是你所谓的 手贱，而是正常迭代也会在 Master 上继续提交，
当 dev 分支开发完之后，再 rebase 到 Master 后合并回 Master 即可
1 个赞
rebase 以前的机制是生成 patch 补丁，然后到新分支上面去打，所以每一个 commit 补丁都可能遇到冲突，你有1000各commit 补丁遇到冲突，就需要解决冲突1000次，比较坑，但最终得到的提交历史比较清爽
谢谢提醒，实践出真知 
完全同意，看了前面几楼，就是这么个感觉。
楼主应该实际用起来，对基本概念有一些了解／体会之后再来讨论，否则别人写了一大堆，你看得云里雾里，于双方都无裨益。
另外要吐槽一下配图，画得真难看，尤其
EDIT：图片应该是用工具生成的，虽然有点歪歪扭扭，但如果配色合理一些，还是可以接受的。
这个颜色有点朋克，闷骚型颜色。。。。
cyberpunk 的配色其实很讲究，亮眼但是不刺眼：https://blog.depositphotos.com/15-cyberpunk-color-palettes-for-dystopian-designs.html
楼主链接的配色，跟公安部门在线通告差不多，都是亮瞎眼的配色：
我大一的时候这类教程过了好几个还是不懂 git，后来开个 playground 把 magit 所有选项慢慢试了一遍好多了，需要实际操作加一。
嗯