Using 'Git rebase' to Perfect Commits

#1

Post by adamjhawley » Mon, Feb 07, 2022, 5:21 PM UTC

Using 'Git rebase' to Perfect Commits
adamjhawley.github.io

Re: Using 'Git rebase' to Perfect Commits

#2

Post by gus_massa » Mon, Feb 07, 2022, 5:33 PM UTC

Do you use any GUI? In Windows I use TortoiseGit, and in Linux I use Git Cola. But sometimes I have to use the CLI for strange cases.

Re: Using 'Git rebase' to Perfect Commits

#3

Post by adamjhawley » Mon, Feb 07, 2022, 5:47 PM UTC

gus_massa wrote: post #2

Do you use any GUI? In Windows I use TortoiseGit, and in Linux I use Git Cola. But sometimes I have to use the CLI for strange cases.

Personally, the only GUI I have ever used is GitKraken during my studies. Since then I do a lot of my work on remote servers so CLI has been much more convenient.

I know that some people say using CLI from the beginning is best for learning git but the visualisation from a GUI definitely helped me get to grips with the concepts.

Re: Using 'Git rebase' to Perfect Commits

#4

Post by adhesive_wombat » Mon, Feb 07, 2022, 9:44 PM UTC

Interactive git rebase are a good way to casually flex with Vim to a point and clicker, even if you hardly know anything.

"cws" to change "pick" to "s" ("cwf" for fix up), then "j." to repeat for the next line.

Also one of my favourite aliases is "rn" for interactively rebase the last n commits. Something like "!git rebase -i HEAD~$1" (from memory).

Re: Using 'Git rebase' to Perfect Commits

#5

Post by adamjhawley » Mon, Feb 07, 2022, 9:50 PM UTC

adhesive_wombat wrote: post #4

Interactive git rebase are a good way to casually flex with Vim to a point and clicker, even if you hardly know anything. "cws" to change "pick" to "s" ("cwf" for fix up), then "j." to repeat for the next line. Also one of my favourite aliases is "rn" for interactively rebase the last n commits. Something like "!git rebase -i HEAD~$1" (from memory).

Oh wow, thanks for sharing that alias. That could be super useful, I will definitely try that out.

Re: Using 'Git rebase' to Perfect Commits

#6

Post by acemarke » Tue, Feb 08, 2022, 1:23 AM UTC

Yeah, I've long been a fan of rewriting my feature branches to clean them up before pushing. I wrote an extensive blog post last year describing useful Git techniques and usage patterns [0], and I tried to emphasize that as a key point.

I use SourceTree as my primary Git GUI, largely _because_ it has a UI specifically for interactive rebasing. Fork is another good GUI with interactive rebase support.

[0] https://blog.isquaredsoftware.com/2021/01/coding-career-git-...

Re: Using 'Git rebase' to Perfect Commits

#7

Post by pdpi » Tue, Feb 08, 2022, 1:30 AM UTC

gus_massa wrote: post #2

Do you use any GUI? In Windows I use TortoiseGit, and in Linux I use Git Cola. But sometimes I have to use the CLI for strange cases.

I use Sublime Merge (same people as Sublime Text), and the licence was money well spent.

Re: Using 'Git rebase' to Perfect Commits

#8

Post by u801e » Tue, Feb 08, 2022, 1:35 AM UTC

I've found that separating work from recording that work is the easiest approach. So what I end up doing is waiting the code and tests and making sure things work as expected. Only then will I start recording that work into a sensible series of commits.

To do this, I'll generate the diff of my work relative to the base branch and then stage parts of that work using the git apply command and make a commit out of it.

If it turns out that I need to update what I changed in a commit I already made, I'll just make a fixup commit (by creating a commit with the changes and titling it with

    fixup! Exact title of commit

This way, when I run a rebase with the autosquash parameter, git will rearrange the commits such that the fixup commit is listed right after the commit I want to amend.

If I just need to update the commit message itself, I'll do the same thing except that I use the squash! prefix instead of fixup!. I then make the commit using the allow-empty option (making sure I have no changes states in the git index). During the autosquash rebase, this brings up the editor where I can delete the text except for the updates commit message I typed earlier.

Re: Using 'Git rebase' to Perfect Commits

#9

Post by kadoban » Tue, Feb 08, 2022, 1:56 AM UTC

u801e wrote: post #8

I've found that separating work from recording that work is the easiest approach. So what I end up doing is waiting the code and tests and making sure things work as expected. Only then will I start recording that work into a sensible series of commits. To do this, I'll generate the diff of my work relative to the base branch and then stage parts of that work using the git apply command and make a commit out of it. I…

That sounds like too long to wait to commit, by my judgement. There's too much risk of loss of work, or at least annoyance getting it back via editor undo.

What about making smaller commits and going back and editing it later? You could either 'git reset --soft' to "undo" some commit(s) and then craft them how you like, or anything else. Seems like your git skills should easily be good enough to handle that.

By the way, you know about 'git add -p', right? That's a fancier way to do what I think you're doing with diff and apply, though yours may work better for you.

Re: Using 'Git rebase' to Perfect Commits

#10

Post by pyuser583 » Tue, Feb 08, 2022, 3:09 AM UTC

I’ve run into weird situations using git rebase to edit history.

For one thing it doesn’t just edit history, it rebases the branch (shocking!).

Also, you run into extreme weirdness messing with the main (first, not default) branch and initial commit.

I’m an experienced user, so I understand the logic behind the weirdness, but I always caution new developers about it.

It’s “git rebase” not “git branch —edit.”