[kartoffelmos]

It was after discovering/learning `git bisect`, I started really understanding the value of using Git "properly". Being able to pinpoint in which commit an error was introduced is really invaluable.

I `git cherry-pick` all the time when I graft a PR. Sometimes I drift and start doing something unrelated to a task, and I often want to push it as a separate thing. Cherry picking it into another branch is most often how I achieve this. This does mean that I have to be structured in how I construct commits while I work though. Drafting, crafting, fixing and maintaining releases is however probably the most common use case for cherry-picking. Some commits needs to be cherry-picked for other release lanes.

`git worktree` is a feature I've often heard being raved about. I've not yet been able to use it for myself, in out code bases, but I imagine it being very nice if you have it work for you.

Aside: suggestion to add `git switch` and `git restore` to your repertoire. I'm guessing you use `git checkout` for these commands, but switching branches and resetting the staging area are two _very_ different tasks and making these two different commands is a wise decision. Lessens the likelihood for errors, at least for me.

[pinoy420]

Interesting

I have only worked on huge applications that take ages to spin up so bisect was never really an option.

> start doing something unrelated to the task I would change branch to that — if I ever had liberty to change priorities like that.

I have not tried git switch thank you

[kartoffelmos]

We try to have a clean-as-you-go policy. Try to improve bits and bobs while maintaining the code base as a whole. While (IMO) a one-liner here and there is fine, it can quickly spiral out of control.

I usually keep an improvements commit at the start of my branch which I `--amend` to while picking away at the task. If the commit gets too big I submit it separately, to be reviewed in isolation.

[Izkata]

> I have only worked on huge applications that take ages to spin up so bisect was never really an option.

That's the best time to use bisect, set up a script to automate the build and test for the specific thing you're looking for, then use "git bisect auto ./foo.sh" and go to lunch.