@b0rk I love using https://github.com/extrawurst/gitui for adding files or chunks of lines for commit or for quickly viewing changes of a specific commit. The rest is done via cli (including committing). The commit message editor is neovim and it includes preview of the changed lines (`git config --global commit.verbose true`).

@b0rk 💯

Fwiw, I like using a GUI (`git citool`) for crafting commits, whether "complex changes" or not, as seeing the diffs invites me to review the changes before staging and committing them, rather than "blindly" adding the files.

@b0rk I just realized I selected "CLI" as my driver... but I wonder if vim-fugitive counts as a GUI? I use that ALL the time, and in particular to stage changes.

@b0rk For me there are really three avenues: CLI, GUI, and the Bitbucket (or, one upon a time, Github) web interface for branch and pull request management.

I use the git CLI for most local operations, but branches are usually created and merged non-locally through Bitbucket. And when there are conflicts that make that impossible, I use Bitbucket's Sourcetree tool along with Visual Studio Code's merge support to handle them.

@b0rk well that is EXACTLY the case for me at least. :)

@b0rk same for 1) and 2) for me, but I prefer to resolve merge conflicts by hand.

I use https://GitUp.co to handle complex staging needs, a mix of that and Sublime Merge for history, and I also use GitUp for editing branches (as a better interactive git-rebase; you can delete, rearrange, and edit commits without having to do them in a batch, so you get feedback more quickly.)

@b0rk I use git on the command line as a separation of concerns. Over _here_ I do coding, and over _here_ I interact with git.

@b0rk I like GUI for branch viz.

I used to depend on GUI for staging complex changes, but I’m moving *towards* `git add -p` for that.