1

Our workflow is as follows:

Create a feature branch
Pull from remote
create and commit changes to code
rebase feature branch with changes made to master by other developers
commit changes
*continue to commit and rebase to local branch*
merge feature branch with master

I was hoping that after I had set up KDiff3 as an External Diff / Merge Tool, from my feature branch I would be able to "Rebase Children of Commit-ID-of-master" (so that I could squash commits in some situations). Instead, the only alternative that I have found is specifically highlighting the origin/HEAD in my feature branch commit history and typing 'Ctrl+D' (External Diff). At that point I can work through changes, save a revised version, and commit that before trying to rebase again. Is it possible to force the diff to automatically pop up any time there are base conflicts and fix them real time so that the rebase continues instead of automatically aborting?

trevor4n
  • 281
  • 1
  • 3
  • 11
  • Why not just merge the changes on `master` to the local branch rather than rebasing? Then you just resolve merge conflicts and keep working. – Sebastian Lenartowicz Jul 12 '16 at 17:13
  • I'm still not quite sure I follow - the "canonical" `git` workflow is that, if `topic` diverges from `master`, you merge `master` into `topic` so that any following work is then being done on top of the latest code. Then, when you're done on `topic`, you merge the whole thing back into `master`. I'm not quite sure I understand what you mean by "historically intuitive", either. I understand wanting to keep a clean branch history, but you shouldn't mess with history that other people have seen/can have access to. – Sebastian Lenartowicz Jul 12 '16 at 18:00
  • The workflow involves rebasing regularly **from the master onto the feature branch**. In this way, the public records (including Commit ID's) are not modified in a way that would create problems for other developers. Rebase is used for its ability to show a feature branch's dependency upon updates merged to the master by other developers. _When a feature is merged onto the master, it represents the fact that it is totally stable and ready to serve as a "base" for other feature branches that will rebase it (therefore burrying it below their own commits to serve as a necessary foundation)._ – trevor4n Jul 12 '16 at 19:33

0 Answers0