7 ms·

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see and understand what's going on. As a Junior Engineer, a Senior Engineer recommended it to me. I thought he was joking at first, but he kindly reminded me that using a GUI app is completely fine and okay. We shouldn't stigmatise tools that make it easier to use and understand your workflow. GitHub desktop allows me to see what i'm committing, commit history and much more. I'd definitely recommend it. PS. Using it is not an excuse not to learn how to use the CLI. Others will accuse me of being lazy and not learning best practice. Learn both. Use the easier one.

jamisonbryant 4y ago
> Learn both. Use the easier one. This is a great point that I will be sharing with my team. Sometimes (most of the time) I use the git cli, and sometimes I use the built-in Git pane in VS Code. I have not used GitHub Desktop in quite a while. In your opinion does it make the commit graph easy-to-read? Because I have not found a tool _yet_ that makes that diagram easily parseable by the human eye. It just looks like a mountain of spaghetti commits linked together with a myriad of colored lines. (I realize that part of the cause of my confusion is crappy discipline around commit history, but what can you do on a team of a certain size where you're not the lead? Just have to suck it up.)
- nevada_scout 4y ago
  Github Desktop doesn't have a commit graph. It only shows a list of commits for a selected branch.
  - kyawzazaw 4y ago
    SourceTree does well in this regard.
ezfe 4y ago
Sublime Merge here, love it and won't go near the CLI anymore
- tylerscott 4y ago
  Seconding Sublime Merge. I've been using it since it was launched and it has been a solid tool.
RadiozRadioz 4y ago
The reason people on here tend to dislike those types of tools is because they've probably been the ones who had to fix the tangles people get themselves into by using those tools. Tools that obscure details in favor of simplicity are fine in some cases, but version control is an inherently complex problem domain where having those details is important. In my experience mentoring juniors new to git, those who are just given a few basic commands don't create as much of a mess because they don't have the commands required to make a big mess. When they do make a mess, it's usually because they've copy-pasted something from the internet, and most will acknowledge that blind copy-pasting _feels_ wrong. Give them a GUI, and suddenly there are buttons to create all sorts of unholy mangles right at their fingertips. As a really simple example, one of the most frequent things I see from juniors using git GUIs is adding files to a commit that they didn't intend to (say stuff that's not in the .gitignore, but doesn't belong in the commit). In the CLI, they probably don't know about -a, so they would be forced to add files/directories individually and think about what to include. Most GUIs I've seen include a "Stage All" button front-and-center, which is very tempting for a new user to click (or, worse, they make staging an opt-out thing). I do not know if this specific example is the case in GitHub Desktop, it's something that I see regularly. I agree with your last point. I think git GUIs are best for users who already know what they're doing and find that a GUI speeds up their workflow.
- dullcrisp 4y ago
  > they probably don't know about -a How are you going to keep them from learning about -a?
  - xmprt 4y ago
    When I first learned git, I had no idea what staging meant and the differences between A, M, D, R, AM, etc... Only some time later (albeit a short time) I learned about -a, at which point I had a bit more understanding of the statuses and what it meant to stage a change. If you gave me -a before that, I would have never understood those things properly.
- make3 4y ago
  the other thing is that this likely doesn't work over ssh
matkoniecz 4y ago
> It has all the bells and whistles of the CLI Somehow I strongly doubt it. Does it have at least access to cherry picking, reflog and rebasing?
- burkaman 4y ago
  Yes you can rebase, and drag-and-drop commits to cherry-pick. Not sure about reflog, but I think the visual interface sort of replaces some of the need for it.

jamisonbryant 4y ago

> Learn both. Use the easier one. This is a great point that I will be sharing with my team. Sometimes (most of the time) I use the git cli, and sometimes I use the built-in Git pane in VS Code. I have not used GitHub Desktop in quite a while. In your opinion does it make the commit graph easy-to-read? Because I have not found a tool _yet_ that makes that diagram easily parseable by the human eye. It just looks like a mountain of spaghetti commits linked together with a myriad of colored lines. (I realize that part of the cause of my confusion is crappy discipline around commit history, but what can you do on a team of a certain size where you're not the lead? Just have to suck it up.)

nevada_scout 4y ago
Github Desktop doesn't have a commit graph. It only shows a list of commits for a selected branch.
- kyawzazaw 4y ago
  SourceTree does well in this regard.

ezfe 4y ago

Sublime Merge here, love it and won't go near the CLI anymore

tylerscott 4y ago
Seconding Sublime Merge. I've been using it since it was launched and it has been a solid tool.

RadiozRadioz 4y ago

The reason people on here tend to dislike those types of tools is because they've probably been the ones who had to fix the tangles people get themselves into by using those tools. Tools that obscure details in favor of simplicity are fine in some cases, but version control is an inherently complex problem domain where having those details is important. In my experience mentoring juniors new to git, those who are just given a few basic commands don't create as much of a mess because they don't have the commands required to make a big mess. When they do make a mess, it's usually because they've copy-pasted something from the internet, and most will acknowledge that blind copy-pasting _feels_ wrong. Give them a GUI, and suddenly there are buttons to create all sorts of unholy mangles right at their fingertips. As a really simple example, one of the most frequent things I see from juniors using git GUIs is adding files to a commit that they didn't intend to (say stuff that's not in the .gitignore, but doesn't belong in the commit). In the CLI, they probably don't know about -a, so they would be forced to add files/directories individually and think about what to include. Most GUIs I've seen include a "Stage All" button front-and-center, which is very tempting for a new user to click (or, worse, they make staging an opt-out thing). I do not know if this specific example is the case in GitHub Desktop, it's something that I see regularly. I agree with your last point. I think git GUIs are best for users who already know what they're doing and find that a GUI speeds up their workflow.

dullcrisp 4y ago
> they probably don't know about -a How are you going to keep them from learning about -a?
- xmprt 4y ago
  When I first learned git, I had no idea what staging meant and the differences between A, M, D, R, AM, etc... Only some time later (albeit a short time) I learned about -a, at which point I had a bit more understanding of the statuses and what it meant to stage a change. If you gave me -a before that, I would have never understood those things properly.
make3 4y ago
the other thing is that this likely doesn't work over ssh

matkoniecz 4y ago

> It has all the bells and whistles of the CLI Somehow I strongly doubt it. Does it have at least access to cherry picking, reflog and rebasing?

burkaman 4y ago
Yes you can rebase, and drag-and-drop commits to cherry-pick. Not sure about reflog, but I think the visual interface sort of replaces some of the need for it.