合并后的交互式重新分区/其他提交交织我的 [英] Interactive rebase after merging/other commits interleaving mine

问题描述

我的典型git工作流是在我们的主分支上创建一个功能分支，进行小的提交，同时定期合并，以便跟上主流。

我然后在github上打开pull请求，当它被接受时，我将删除分支。我想交互式地更换，但是当我这样做时，我会遇到合并提交和其他人的提交与我自己的交错。我不知道如何/如果我可以压缩这些提交或组/挤压我一个人？

例如，我的分支的git日志可能看起来像这样来到时间rebase：

 合并提交
其他人的提交
我的一个提交
另一个我的提交
另一个合并提交
另一个人的提交
我的一个提交，第一个分支
  

在进行交互式重新分页并压缩和重新排序提交时，我遇到了什么可能的问题以及什么问题。鉴于上述工作流程，您会推荐什么？

解决方案

我们在办公室使用的流程是重新绑定到 master 分支（或者你期望合并到的任何分支），然后合并你的请求。这可以确保您的提交在当前位于 master 中的所有其他提交之上进行排序，从而消除了您与其他提交的交错：

 > git fetch upstream master 
> git rebase upstream / master 
  

My typical git workflow is to make a feature branch off our master branch, make small commits, while periodically merging from master along the way to keep up.

I then open a pull request on github and when it's accepted I'll delete the branch. I'd like to interactively rebase more but when I do I'll encounter merge commits and other people's commits interleaved with my own. I'm not sure how/if I can squash those commits or group/squash mine alone?

For instance, my git log for my branch might look like this when it comes time to rebase:

merge commit
someone else's commit
one of my commits
another one of my commits
another merge commit
another person's commit
one of my commits, the first one after branching

I'm having trouble with what's possible and what's not when doing an interactive rebase and squashing and reordering commits. Given the above workflow, what would you recommend?

解决方案

The process we use in my office is to rebase to the master branch (or whatever branch you expect to merge into) before merging your pull request. This ensures that your commits are ordered on top of all the other commits currently in master, which eliminates the interleaving of your commits with others:

> git fetch upstream master
> git rebase upstream/master

这篇关于合并后的交互式重新分区/其他提交交织我的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！