Comment by nerdjon | Hacker News Reader

Comment by nerdjon | Hacker News Reader

Parent Full thread

The UI does look really good, but I do wonder how much of the dev community uses a GUI vs just sticking in the command line?

Personally the only GUI stuff I find useful are the features that are already part of VSCode (live showing what I have changed or doing a diff). Outside of that I generally find that any GUI for git just inevitably makes something just opaque enough that I don't really know for sure what I am about to commit or where I am pushing too. For me "git status" >> "git add XYZ" >> "git status" >> "git push" are so ingrained in my workflow that I don't get that feedback in any UI I have seen.

I have started to dip my toes into it a bit now with the Atlassian integration that can name new branches properly... but even using that just gives me a weird disconnect with what is actually happening that it doesn't feel right. After the creation of the branch I am back to my cli.

Maybe it is just because I live in the command line anyways (enough so that I have iTerm setup to just pop up from the bottom of my screen with a keyboard command) that I just feel more comfortable with the command line?

I just feel like I am missing something here since I know some do rely on these tools heavily.

I work 100% in a git UI. Everything but merge diffs I do in Sourcetree... for diffs I use VS. It's how I've learned. Here's some of my scattered reasoning:

- It's a separate, dedicated application to do just my source control

- Keeping repos in tabs makes it easy to switch between projects (yes, you could use screen or some other multiplexer, but it's just not as fast for me)

- I'm Windows

- Easier to review history / merges at a glance

- Sucks that SourceTree doesn't have diffing, but it's much easier to do diffs/merge conflict resolution in a UI

- Clicking through items to see what's staged/unstaged is quick

I like SourceTree’s ‘branch diff’ (and it’s the only thing I use it for).

Mostly same here. UI makes life really easy for me.

I use both the git CLI and Fork for different tasks. For the `git add` workflow you describe I use the CLI exclusively, and for interactive rebase it's about half and half.

An example where Fork comes in handy is deleting branches, especially on remotes. It's pleasant to see all the branches and just click on the ones I want to delete, and not have to deal with git CLI's differences between deleting local and remote branches, or remember how git deletes remote branches this week.

Same here. I find merging branches (and viewing the results) easier with Fork, too, while I do the simpler things in the terminal.

In my case my git usage is so mundane that the most basic of its CLI commands are sufficient 98% of the time. Reaching for the more advanced commands is so infrequent that they don't ever stick meaning I'm always looking them up (and probably subsequently screwing them up).

My work is scattered across different IDEs/editors too so the differing UI conventions of integrated VCS make that more trouble than it's worth.

So I just use Fork all the time. It covers base case very well regardless of the project, and on the occasion that I need to do something more fancy I can do it without pulling up docs and with far fewer screwups.

I find it much easier and faster to stage or unstage files (or parts of files) with a UI.

Reply on news.ycombinator.com