[heydenberk]

If you get a lot of value out of the pull request view, you might enjoy adding partial committing to your workflow. Rather than committing entire directories or folders at a time, you can page chunk by chunk through uncommitted changes, committing only the ones you select. You'll easily spot those stray logging statements you don't want to commit. (You can also discard chunk at a time by using partial checkout/restore.) If you have, for example, two pairs of backend/frontend changes that you want to commit logically rather than simply according to their directory structure, partial committing is handy.

It's just `git commit -p` (and `git checkout -p`). It's not exactly a deep cut, but I encourage people who are familiar but don't use it to give it a try.

[tomschlick]

You can commit line by line within Github Desktop and its a much nicer experience IMO than doing so via CLI. Its much easier to jump around to different files and commit related line changes in a bigger PR than jumping in and out of the patch command.

[Symbiote]

  git gui

which you probably already have if you use Linux also has this functionality.

[devanl]

It's been a while since I've tolerated the git gui interface, but when I used to use it, the line-to-chunk logic would regularly fail on short 2-3 line spans.

There's a stackoverflow discussion [1] that suggests it was fixed in 2018, but for many years it was a terrible experience that pushed me to use other frontends just for reliable partial staging.

1: https://stackoverflow.com/questions/58133092/git-gui-error-f...

[tomschlick]

It does, but github desktop is way better looking and has deeper integration into github prs, status checks, etc.

[btown]

For those who want a GUI around this on Mac, https://rowanj.github.io/gitx/ is an incredible secret weapon. You can swipe over a bunch of lines or let the software identify a whole span of contiguous changed lines, click a button, and see just those changes move over from your unstaged to staged changes, then commit exactly what you want.

A lot of times people don't even understand how powerful the staging area is; they're just used to saying git add && git commit without realizing that it can be an incredible way to take a day of chaotic fixes and turn it into a set of commits you can be proud of!

It also provides an incredible tree view of commit parentage, perfect for when you need to instantly understand what happened with this weird merge/rebase that broke things, and to screenshare it to teach colleagues who might not have developed an internal understanding of the tree structure that Git is based on.

The software is now 9 years old and abandoned, but I've used this specific fork at least weekly - often daily - for every one of those years, across Intel and M1 Macs, and it's never let me down!

[jonas-w]

According to this issue[0] there is a newer and maintained version of gitx.

[0] https://github.com/rowanj/gitx/issues/481

[noloblo]

https://github.com/gitx/gitx/releases my daily driver in mac

[btown]

Huh, it was just accepted as the mainline fork in Homebrew last week! Been trying it and it seems to have all the features that the rowanj fork had! https://github.com/Homebrew/homebrew-cask/pull/141659

[stdohm]

Been using GitX for many years . Happy to learn there’s a new fork. Thanks!

[aldanor]

There's decent well maintained git ui clients for Mac, eg Fork

[iamcreasy]

Can you briefly explain what you meant by staging area is powerful?

[Rushsick]

I assume it’s the fact that staging changes takes them out of your working tree. From there, a lot of git operations (diff, restore) will not include or modify the staged changes. This can help reason about logical chunks of code within a commit

[steve_adams_86]

Interesting, I knew of `git add -p` (which I then use to `git commit -m ...`, but it looks like I could add all changes and _then_ decide what to commit. I think I'd still use `add -p` (I like being thorough), but I like that I can add all at once and then make partial commits based on specific change sets.

Thanks for pointing this out, I feel like git is the thing I should know best by now yet I'm missing so much of what it can do. It's great to see others' workflows.

[brasic]

My favorite git workflow extension is `git commit --fixup SHA` combined with `git rebase -i --autosquash` to create targeted retroactive amendments. Kind of like `commit --amend that can target more than just the last commit.

I wrote https://github.com/brasic/fixdown to make this easier to use.

[tracker1]

I've tended to have a similar workflow... but since I use VS Code mostly, then I do use the git tab a lot for previewing changes before committing them. Other than that, I've mostly avoided using any GUI for git, mostly because I find it annoying. I'll say that the Github client and the VS Code integrations for Github have come a long way all the same for those that use and like them.

[tomodachi94]

This functionality is built-in to vim-fugitive and VS Code.

In Fugitive, open it with :Git , select the unstaged file then press = . Select the desired range with visual mode, then press s and commit as normal.

In VS Code, select a hunk, press Ctrl+P, then type "Stage Selected Range." Repeat this process and commit as normal.

Edit: formatting and typo.

[Hasnep]

I commit small chunks so often that I have a keyboard shortcut set up for that "stage selected range" command in VSCode, definitely recommend it to get a more useful commit history.

[brasic]

Plenty of git commands support a -p mode. I like `git stash -p`.