-1

At my job, I have the current commit workflow.

I commit a change onto master, then submit for CR (code review).

--EDIT-- NOTE, THE CODE REVIEW PROCESS DOESN'T INVOLVE A PUSH TO ORIGIN, I.E. I AM NOT REWRITING REMOTE HISTORY.

If I do changes to address the CR, I don't make a new commit but I instead use git commit --amend on the old commit on master.

i.e.

master: A (out for CR) --\
dev:                      \ -- B.

make changes on A, so now my tree looks like this:

master: A' (modified A created with commit --amend)
dev: A -- B

What I want is an easy way to make it look like

master: A' --\
dev:          \-- B

I continue to work on a feature on top of the old one by branching. I can't do a simple rebase because the --amend command deletes the old commit on master.

Right now, what I'm doing is I'm rebasing master and then doing an interactive rebase to delete the old A from the history on dev. Is there a better way?

Hongyu Wang
  • 378
  • 1
  • 10
  • What do you call CR here? Be explicit, it's better. Not everybody uses the same jargon, let alone the same shortcuts. Also, the schema is strange. Commit `A` seems to go on and off branch `dev`. Is it on or not? *That* should not depend on what you're doing to `master`. – Romain Valeri Oct 09 '19 at 21:17
  • A is still on dev because the amend created a new commit @RomainValeri – D. Ben Knoble Oct 10 '19 at 03:22

1 Answers1

2

Why you shouldn’t amend pushed history

(OP has clarified he is not pushing to master, so this is more for future folks.)

You’re going to create a headache doing this—one full of force-pushed, public history re-writes, and really bizarre pulls.

Really, just don’t.

It’s the same as rebasing pushed history.

Don’t do it. You have been warned.

If you insist

As long as B still applies cleanly to A', you can do something like

git checkout dev
# take all commits from A and put them on master (A')
git rebase --onto master A

or

git checkout -b newdev master
git cherry-pick dev
git branch -D dev
git branch -m dev

(I might have the move syntax wrong on the last line.)

Point is, please don’t do this. It’s fine to rewrite local history. Once you’ve pushed it, don’t rewrite and push to the same place. Push to a new branch instead.

D. Ben Knoble
  • 4,273
  • 1
  • 20
  • 38
  • Everything is still local history. A code review is issued on an existing commit before it gets pushed into origin/master. – Hongyu Wang Oct 10 '19 at 03:44
  • It also appears that there's no way to do this without cherry picking the commit eh. Ok. The reason why I'm using this workflow is because I'm used to it in mercurial where I amend the commit and then use hg evolve to apply the commit to all future commits. Thanks. – Hongyu Wang Oct 10 '19 at 03:46
  • Accepting answer because it confirmed my suspicions – Hongyu Wang Oct 10 '19 at 03:50
  • Unaccept, better answer is here: https://stackoverflow.com/questions/35901915/how-to-rebase-after-squashing-commits-in-the-original-branch – Hongyu Wang Oct 17 '19 at 20:40
  • @HongyuWang if you just want the better syntax, I'll update – D. Ben Knoble Oct 17 '19 at 20:55