Is there a way to rewind the git rebase state?
-
How does cherry picking improve the workflow? I'm not sure I understand, is it so you can keep the original branch as reference and know where you could have screwed up if it happens?
is there a way to move commit out of the way Todo later?
This is what
cherry-pickdoes for me. Now that the work is all done, I cancherry-pickthe commits into the new branch in any order I find convenient (and often in an order that causes fewergitconflicts, or nogitconflicts to resolve.)Note that this approach is much stronger if the original commits are fairly focused and purposeful.
In extreme cases, I stop and rebase the new or old branch to clean up the commits before I
cherry-pickthem onto the same branch.In essence, all of these techniques are just ways for me to very slowly and methodically organize thoughts, using
git.Also, sometimes it's all too messy and I just copy and paste all the change I need into a fresh clean branch.
-
Not exactly, because n commits will have been squashed into one, so making the edit would lose the reference to the originals which should have been squashed with other commits, visually maybe this helps:
A (pick) -> B (squash) -> C (squash) -> D (pick)When it should have been:
A (pick) -> B (squash) -> D (pick) -> C (squash)I had just created A+B+C, then realised C should have been out
Not exactly, because n commits will have been squashed into one, so making the edit would lose the reference to the originals which should have been squashed with other commits
See but you can break the commit back apart by doing a git rebase interactive, selecting that squashed commit as the commit to edit, then doing a
git reset HEAD~1then recommit it in pieces, thengit rebase --continue -
is there a way to move commit out of the way Todo later?
This is what
cherry-pickdoes for me. Now that the work is all done, I cancherry-pickthe commits into the new branch in any order I find convenient (and often in an order that causes fewergitconflicts, or nogitconflicts to resolve.)Note that this approach is much stronger if the original commits are fairly focused and purposeful.
In extreme cases, I stop and rebase the new or old branch to clean up the commits before I
cherry-pickthem onto the same branch.In essence, all of these techniques are just ways for me to very slowly and methodically organize thoughts, using
git.Also, sometimes it's all too messy and I just copy and paste all the change I need into a fresh clean branch.
I see, now that makes sense to me as well! I too make commits messily as thoughts crop up, so I think this technique might be good for me in some cases, thanks!
-
Not exactly, because n commits will have been squashed into one, so making the edit would lose the reference to the originals which should have been squashed with other commits
See but you can break the commit back apart by doing a git rebase interactive, selecting that squashed commit as the commit to edit, then doing a
git reset HEAD~1then recommit it in pieces, thengit rebase --continueI know, but that feels really clunky to me, like an unclean solution, I know that commit will disappear regardless, but I don't like room for more human error like that by manually re-editing
-
I know, but that feels really clunky to me, like an unclean solution, I know that commit will disappear regardless, but I don't like room for more human error like that by manually re-editing
Don't know what to tell you. Been doing it that way since 2011
-
System shared this topic on
