1.首先切换到分支 git checkout 分支 2.使用git pull 把分支代码pull下来 git pull 3.切换到主分支 git checkout master 4.把分支的代码merge...到主分支 git merge 分支 5.git push推上去ok完成,现在 你自己分支的代码就合并到主分支上了 git push
这个 mainline 是主线，也是我们要保留代码的主分支，从 feature 分支往 develop 分支合并，或由 develop 分支合并到 master 的提交还好确定，但 feature 分支互相合并时...合并 commit2 ~ commitN 到最旧的 commit1 上 在合并 commit 时，我们可以选择 pick(p) 最旧的 commit1，然后在后续的 commit_xxx 前添加 squash...合并 master 到 rebase-rollback 由于 rebase-rollback 分支落后与 master 分支，因此需要执行 git merge master 将主分支向 rebase-rollback...分支合并，合并后 git 会发现 commit1 到 commit4 提交的内容和 rebase-rollback 分支上 commit5 的修改内容是完全相同的，会自动进行合并，内容不变，但多了一个...合并 rebase-rollback 到 master # 切回到 master $ git checkout master # 合并 rebase-rollback $ git merge rebase-rollback
，而这个时候master分支已经被更新了 如果B同学开发完毕，需要将其所作的功能合并到master分支 ，他可以有两种选择： 直接git merge，那么这个时候会这么做 （1）找到master和dev...的共同祖先，即C2 （2）将dev的最新提交C5和master的最新提交即C6合并成一个新的提交C7，有冲突的话，解决冲突 （3）将C2之后的dev和master所有提交点，按照提交时间合并到master...直接git rebase 切换分支到需要rebase的分支，这里是dev分支 执行git rebase master，有冲突就解决冲突，解决后直接git add ....再git rebase --continue即可 发现采用rebase的方式进行分支合并，整个master分支并没有多出一个新的commit，原来dev分支上的那几次（C3，C4，C5）commit记录在...rebase之后其hash值发生了变化，不在是当初在dev分支上提交的时候的hash值了，但是提交的内容被全部复制保留了，并且整个master分支的commit记录呈线性记录 此时git的分支类图 总结
$ git fetch origin $ git rebase origin/master 第五步：合并commit 分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个...$ git rebase -i origin/master git rebase命令的i参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。...fixup：与squash相同，但不会保存当前commit的提交信息 exec：执行其他shell命令 上面这6个命令当中，squash和fixup可以用来合并commit。...interactive rebase, squash, amend 运行结果相同，还是会生成两个commit，第二行和第三行的commit，都合并到第一行的commit。...squash和fixup命令，还可以当作命令行参数使用，自动合并commit。
然后再切回到master分支上，进行一次新的提交（C3）。 最后要做的就是在master分支上执行一次合并操作，将bugFix分支上的提交合并到master分支上，C4就是合并后的节点。...最后的话，就是在 master 分支上执行 git merge bugFix命令，将bugFix分支合并到master分支上，合并后会生成一个新的C4节点。具体如下所示： ? ...执行变基后，C2会和C3节点的内容进行合并生成新的节点C2`，而bugFix分支的指针也会从C2节点移动到C2`上，移动后bugFix之前的分支就会被废弃掉，取而代之的是从master延续下来的新分支。...交互式rebase操作成功后，接下来我们来看一下当前分支的情况，，从结果中我们不难看出： bugFix 分支上的提交已经变基到了master分支上。...4、交互式rebase的squash操作 接下来我们来看一下squash的操作，下方我们会在当前所在分支和上次提交上执行squash操作，其对应的命令的为：git rebase -i HEAD~1，如下所示
git add 命令的all参数，表示保存所有变化（包括新建、修改和删除）。从Git 2.0开始，all是 git add 的默认参数，所以也可以用 git add . 代替。...$ git fetch origin $ git rebase origin/master 第五步：合并commit 分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个...$ git rebase -i origin/master git rebase命令的i参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。...fixup：与squash相同，但不会保存当前commit的提交信息 exec：执行其他shell命令 上面这6个命令当中，squash和fixup可以用来合并commit。...interactive rebase, squash, amend 运行结果相同，还是会生成两个commit，第二行和第三行的commit，都合并到第一行的commit。
四、Rebase 场景二：分支合并 1.我们先从 master 分支切出一个 dev 分支，进行开发： git:(master) git checkout -b feature1 2.这时候，你的同事完成了一次...hotfix，并合并入了 master 分支，此时 master 已经领先于你的 feature1 分支了： 3.恰巧，我们想要同步 master 分支的改动，首先想到了 merge，执行： git...master 分支； 最后，把上面保存的 patch 文件应用到 feature1 分支上； 从 commit 记录我们可以看出来，feature1 分支是基于 hotfix 合并后的 master...： 提交后远程分支变成了这样： 而此时你的同事也在 feature1 上开发，他的分支依然还是： 那么当他 pull 远程 master 的时候，就会有丢失提交纪录。...结论：只要你的分支上需要 rebase 的所有 commits 历史还没有被 push 过，就可以安全地使用 git-rebase来操作。
这里， git branch feature 创建一个叫做 feature 的新分支并指向你最近的 commit，但还是让你 check out 在 master 分支上。...及时分支，省去繁琐 场景: 你在 master 分支的基础上创建了 feature 分支，但 master 分支已经滞后于 origin/master 很多。...现在 master 分支已经和 origin/master 同步，你希望在 feature 上的提交是从现在开始，而不是也从滞后很多的地方开始。...我们有更好的办法。 git rebase master 会做如下的事情： 首先它会找到你当前 check out 的分支和 master 分支的共同祖先。...如果你需要把两个 commit 合并到一起，你可以使用 squash 或 fixup 命令， squash 和 fixup 会“向上”合并 — 带有这两个命令的 commit 会被合并到它的前一个 commit
二. git 分支管理策略 主分支 master 所有提供给用户使用的正式版本，都在这个主分支上发布。 开发用分支 dev 用于日常开发。...如果想正式对外发布，就在 master 分支上，对 dev 分支进行『合并』（merge）。 临时分支 新的临时分支从 origin/master 拉取, 保证代码最新。使用完毕后，需要及时删除。...和 master 分支。...squash） git commit --amend 另，merge 代码时如想合并多个 commit，可使用 git merge --squash。...推荐 以下内容推荐但不强制（当你明确了解这些操作可能造成什么样的后果以及能解决什么问题时再考虑使用）： 未推送过的分支使用 git rebase 代替 merge 合并 master 分支 merge
edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e） squash：将该commit和前一个commit合并（缩写:s） fixup：将该commit和前一个commit...所以现在我们来试一试使用git rebase，我们先回退到同事 hotfix 后合并 master 的步骤，我现在不使用merge进行合并了，直接使用rebase指令 $ git rebase master...，把上面保存的 patch 文件应用到 dev 分支上； 从 commit 记录我们可以看出来，dev 分支是基于 hotfix 合并后的 master ，自然而然的成为了最领先的分支，而且没有 merge...不过，如果你的分支上需要 rebase 的所有 commits 历史还没有被 push 过，就可以安全地使用 git-rebase来操作。...git-rebase 很完美，解决了我们的两个问题： 合并 commit 记录，保持分支整洁； 相比 merge 来说会减少分支合并的记录； 使用rebase操作要注意一个问题，如果你的分支上需要 rebase
你可以使用 git rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。...示例： 你创建了一个分支 server，在该分支上做了一些修改，提交了 C3 和 C4。 然后从 C3 上创建了新的分支 client，又在client分支上做了一些修改，提交了 C8 和 C9。...这时就可以使用git rebase命令的--onto选项，选中在client分支里但不在server分支里的修改（即 C8 和 C9），将它们在 master 分支上重放： $ git rebase -...分支和 server 分支的共同祖先之后的修改，然后把它们在 master 分支上重放一遍”，结果如图： 现在可以快进合并 master 分支了。...现在就可以快进合并主分支 master 了； $ git checkout master $ git merge server 至此，client 和 server 分支中的修改都已经整合到主分支里了，
记录一下日常的 git 使用与我平时用的 git 小窍门. 关于 rebase 为什么不能在 master 上做 rebase 操作?...核心的原因在于 rebase 会将需要移动的 commit hash 重新生成一遍. rebase 的本质是将需要衍合分支上的 commit 从与当前分支最近祖先 commit 起的所有 commit..., 而是从当前的 feature 分支上 切出了一个分支, rebase -i rebase 后面加上 -i 参数, 其实是交互式的 rebase 命令.它可以可以修改 commit 信息, 顺序,...reflog 了. merge --squash git merge --squash 是合并 merge 操作.遇到的场景是你需要在 deve 分支上修复某个 bug, 你需要切出一个 bugfix...--squash 让 bugfix 分支上的提交合并为一个提交(fix xxx bug)然后合并到 deve. git add -p 所谓 -p 其实是 --patch, 也就是块级, 补丁的意思.git
分支的合并(merge) 对于merge而言，又有两个合并策略： fast-forward no-fast-forward 假设bugfix分支是从master分支分叉出来的,以这个图作为初始分支状态...变基(rebase) reabse和merge其实都可以看作为合并操作，rebase 的优势就是可以创造更线性的提交历史,还是以这张图为列 ?...执行以下命令: //rebase bugfix分支到master分支 ➜ ~ git:(master) ✗ git rebase bugfix ?...现在 bugFix 分支上的工作在 master 的最顶端，同时我们也得到了一个更线性的提交序列。rebase之后，唯一的问题就是 master的HEAD位置还没有更新。...为一个，这时候就可以用squash merge把某个分支上的所有提交都合并成一个提交 git merge --squash 分支名
为了合并 dev 分支到 master 分支，同时确保代码不丢失且提交记录规整，你可以使用交互式的 git rebase 命令。这允许你重新排列、修改、合并或分割提交。...以下是操作步骤： 确保当前在 dev 分支： git checkout dev 交互式地 rebase 到 master 分支： git rebase -i master 这会打开一个编辑器，列出所有...要合并多个提交，可以将相应行的操作从 pick 更改为 squash 或 fixup。squash 会将提交合并到前一个提交中，并允许你编辑提交消息。...fixup 会将提交合并到前一个提交中，但会丢弃当前提交的消息。 要修改某个提交，将操作从 pick 更改为 edit。 完成调整后，保存并关闭编辑器。Git 会执行你指定的操作。...rebase 完成后，切换回 master 分支： git checkout master 将 dev 分支合并到 master 分支： git merge dev 将更改推送到远程仓库： git push
七、在master繁殖的基础上创建了feature分支，但master分支已经滞后origin/master很多。...现在master分支已经和origin/master同步，你希望在feature上的提交从现在开始，而不是从滞后很多的地方开始。...git rebase master会做如下事情： Ø 首先他会找到你当前check out的分支和master分支的共同祖先。...Squash和fixup会向上合并，带有这两个命令的commit会被合并它的前一个commit里。...如果选择squash，git会提示给新合并的commit一个新的commit消息；fixup则会把合并清单里第一个commit的消息直接给新合并的commit。
你可以提供要返回的分支名称或特定 SHA，或者默认情况下，Git 会假设你要切换到 HEAD，即当前分支上的最后一次 commit。 请记住：你以这种方式“撤消”的任何更改实际上都会消失。...commit ，然后意识到你在 master 分支上。...在这里，git branch feature 创建了一个名为 feature 的新分支，指向你最近的 commit ，但让你依然在 master 分支上。...有一个更好的方法。 git rebase master 做了几件事： • 首先，它找到当前分支和 master 分支之间的共同祖先。...如果你想将两个 commit 合并在一起，你可以使用 squash 或 fixup 命令，如下所示： rebase-interactive2 squash 和 fixup 向上合并 commit ——
rebase 重置 作用: 是重置提效记录。 本质是，当合并其它分支的提交记录后，重整提交记录。 不论是自己开发，还是参加开源项目，有很多时间，需要重整提交记录。美化一下，这时候就很有用了。...需要强调一点：一定是在你自己的分支上rebase，别把master之类的分支rebase掉了。...git rebase 假设你在test_rebase分支进行开发，现在master分支已经有新的提交，test有多次提交，现在你想合并master分支，并提交推送到远程仓库中看起来只有一次提交。...master: test commit1 在 test_rebase分支下执行： git rebase -i master -i: --interactive，即交互式的界面 进入交互模式，用vim...rebase: test commit1 rebase: test commit2 被合并成一条了 图片 中断 rebase 如果过程中退出了，但又不想继续了，执行： git rebase --
你所要做的仅仅是切换回 master 分支。 但是，在你这么做之前，要留意你的工作目录和暂存区里那些还没有被提交的修改，它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。...为此，你需要合并 iss53 分支到 master 分支，这和之前你合并 hotfix 分支所做的工作差不多。...出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。 ? Figure 3-16....一次典型合并中所用到的三个快照 和之间将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。...Git 的这个优势使其在合并操作上比其他系统要简单很多。 既然你的修改已经合并进来了，你已经不再需要 iss53 分支了。 现在你可以在任务追踪系统中关闭此项任务，并删除这个分支。
分支上 新增一个C4提交 ，而C4提交里面有master和bugFix代码库所有的修改。...此时的bugFix代码还没和master 同步（颜色不同），我们还需要执行如下代码： git checkout bugFix; git merge master 1.2 rebase 变基 rebase...注意：提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 rebase 到 master 分支上的 C3 的 副本（内容是一样的，只是commitid更新了）。...最新的commit id也更新 squash 合并commit 选择最新的commit去合并，然后continue发现这一次和上一次的commit msg都有，你可以删除只留下想要的也可以进行修改 然后...git reset HEAD~1 git revert HEAD 如下所见，图1是初始状态（需要撤回 C2 提交）,图2和3 是从图1分别执行 reset 和 revert 后的结果： reset
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
