19 ms·

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less tha

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remember the last time I made an irreversible change to the repo, or had an "oh shit" moment. And that's despite using some interesting git features. - Staging individual files, folders, lines of code, or hunks is easy. Makes maintaining multiple trains of though / addressing bugs while working on other code a non-issue. - It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow. - It's much easier to get an overview of the changes I'm making.

lillesvin 9y ago
My biggest issue with a GUI is that most that I've seen introduce new terms for various stuff, e.g. "sync" in VS Code, or "revert commit" (in Source Tree maybe?) — there's no Git command called "sync" or "revert", so I'm not immediately sure what they do. In a CLI I know exactly what's happening. That's just my opinion though. If people feel comfortable working in a GUI all the more power to them.
- autarch 9y ago
  Git does have a revert command.
  - lillesvin 9y ago
    Yeah, my bad. Must've been "reverse" then. I just remember the revert/reverse dichotomy.
    - lttlrck 9y ago
      Or perhaps it called revert but it wasn’t doing a git revert, it was doing a git checkout to simulate an SVN revert... I’ve seen this in at least one GUI. That kind of crap just makes it harder to unwind problems when things go wrong and to learn the tool.
- bootcampjs 9y ago
  I work with a lot of people who have no idea how git actually works and it is infuriating. They all use the git desktop program, and almost every time I get called over to help, it’s because they didn’t sync or refresh or whatever the hell it does. If you don’t have a good mental model for git, you’re gonna have a bad time.
  - lhabjane 9y ago
    Second this. I was one of those people that needed help when I was learning git. Went full CLI after that and never looked back.
- joonoro 9y ago
  I like Magit because it doesn't try to hide git while still giving all the advantages GP mentioned https://magit.vc/ https://magit.vc/
- Alupis 9y ago
  > no Git command called ... "revert" Maybe not in the way Source Tree uses it, but there certainly is[1]! I've had to use it a few times. > git-revert - Revert some existing commits [1] https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert
  - lillesvin 9y ago
    My bad, then it was "reverse" in Source Tree (or whatever it was).
mmmpop 9y ago
> I think anyone who uses the CLI is either trying too hard Why do you think it's okay to share this opinion?
- lwansbrough 9y ago
  Because this is a forum and nothing I say matters.
- Angostura 9y ago
  What makes you think it is not?
  - Gracana 9y ago
    Because it's rude and antagonistic and it compels a lot of people to post to defend themselves. It's classic trolling.
  - mmmpop 9y ago
    It's not constructive, who cares what you think about CLI users? The fact I'm being downvoted says a lot about the state of this forum.
    - falsedan 9y ago
      Your comment was also trolling: I would have avoided the leading question and just commented on the probable negative interpretation the some CLI users might make of the comment.
- ksk 9y ago
  The problem of course is the question - What gives anyone a right to do anything? What gives you the right to police the comments? What gives me the right to question your questioning? Meta-discussions always get sidetracked..
emeraldd 9y ago
What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.
- welly 9y ago
  If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.
  - Ajedi32 9y ago
    Git Kraken isn't FOSS. The site says "Free for non-commercial use", and AFAIK the source isn't available anywhere. I think maybe the term you're looking for is "freeware"?
    - welly 9y ago
      Ah, you're quite right. I was under the impression it was FOSS - I used it a while ago, preferred Tower and so went back to that.
  - mistersquid 9y ago
    I second your recommendation of Tower. About a year ago, I made a comment right here on HN singing Tower's praise names. [0] It's impossible to sing those names loudly enough. [0] https://news.ycombinator.com/item?id=12677542
  - shagie 9y ago
    Apparently, there is now also a windows version. https://www.git-tower.com/windows https://www.git-tower.com/windows
    - GFischer 9y ago
      Thanks, I had disregarded Tower until I saw your comment :)
Cthulhu_ 9y ago
I don't trust GUI clients; it's easy to not be able to discern the current status, easy to just commit all changes, some of the clients don't respect the pre-push hook, and I've seen other colleagues who have no clue what they're actually doing end up mixing pull and pull --rebase, somehow managing to make duplicate commits with slightly different contents and not having a clue what's going on. Don't use clients if you don't even understand the basic git workflows. And those usually don't support the advanced oh shit situations this article is about.
- lwansbrough 9y ago
  > it's easy to not be able to discern the current status Probably a failure of whatever UI you're using. I manage just fine. The common statement from CLI types is that "it's just whatever you're better at using" which is true conceptually, but practically, again, CLI users make more mistakes either from fat fingers or lack of understanding of git. Understanding git conceptually from a UI point of view is easy. You don't even have to have a full understanding of git to be effective at using it, if the UI is good. I'm shit with the git CLI, but I understand what git is doing. Yes it's easy to do dumb shit in a GUI, the same is true for CLI. In fact, it's less likely that there'd be a button for doing something dumb than it is that a git novice would find some command on StackOverflow and attempt to use it without fully understanding the ramifications of it.
rhodysurf 9y ago
For the most part using git is like five commands and it is definitely fast to use them from the command line if you have some sort of git understanding
rcxdude 9y ago
I've felt a good GUI would make using git far more intuitive, but I've yet to find a good one. They all seem to fail on one front or another (too hard to use, don't expose enough functionality, attempt to enforce one workflow, aren't available on platforms I want, are slow/resource hogs). Usually I use the included gitk to view the repo, and the CLI to manipulate it.
- deleted 9y ago
  [deleted]
aschampion 9y ago
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.
- loup-vaillant 9y ago
  A well made GUI conveys those semantics more clearly than the default command line interface. Automation is easier from the CLI, but I wouldn't be surprised if a GUI turned out to be best for manual interactions. (Note: I use the CLI almost exclusively.)
- cookiecaper 9y ago
  Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.
  - The5thElephant 9y ago
    The counter argument is that if you make an error using the CLI, you end up spending more time fixing it than if you just had the GUI open and watching your repo already, and simply switch to it when you need to commit/push.
- neves 9y ago
  Conflict resolution in a GUI with 3 way merge really beats out a command line.
- The5thElephant 9y ago
  Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well). Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users. Sometimes dev obsession with tool purity does more damage than good.
swalsh 9y ago
I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do it. The GUI get's in my way.
- MonkeyIsNull 9y ago
  > I'm not 100% sure what's going on under the covers. This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.
  - ninkendo 9y ago
    GitHub's GUI is the worst. It has a "sync" button. As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to the CLI.
    - emodendroket 9y ago
      It just pushes the current branch afaik.
      - michaelmior 9y ago
        So it never pulls updates on the remote? That seems like pretty unexpected behaviour.
        emodendroket 9y ago
        It pulls and then pushes, I guess I should say, but I was considering "pulls and..." part of the push operation.
sigi45 9y ago
I work very well on a cli. I can do partial adds faster than you and don't had any 'oh shit' moments for a few years. I do not care if someone is using a gui. My takeaway: - If i can use git on an cli, i can use git on any server with an cli. I do need this for when i use git on my ansible maschine or on my home media server or when doing something with build infrastructure (jenkins -> git -> cli)
deleted 9y ago
[deleted]
Pxtl 9y ago
I use both - to me the big advantage of getting used to GIT CLI is that you learn the tools to handle uncommon operations and automate tasks, which the GUI doesn't give you. When you need to start piping stuff through grep, for example.
- cytzol 9y ago
  GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.
  - Pxtl 9y ago
    We have a naming convention that feature branches are named "feature-[descriptionOfFeature]" here and I wanted to bulk-delete all the merged feature branches that developers had left dangling, without killing the release branches and the like. Grepping helped there. Like I said, super-rare situation.
madeofpalk 9y ago
I've found my sweet spot is using both a GUI (Github app, to be specific) and a CLI. GUI for partial commits and reviewing my change, and then command line for basically everything else (merge, checkout, branch, etc).
deleted 9y ago
[deleted]
CruiseDevice 9y ago
I don't know how much difference does it make using gui or cli. When i was interviwed for my first job i was asked questions on git. And they asked if i use gui or cli.I think they wanted to know if i really know how to use git through cli. I never used gui for git, maybe i will use in the future. I think Ohsitgit is a good resource which i was trying to find on internet for so long.
dasil003 9y ago
You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks. I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split. However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don't want to use whatever shitty editor your tool has in it, I want to use vim with syntax highlighting so I can properly format my commit messages. Even something as simple as viewing a full commit is faster in the CLI because you can just pipe it to less or send it to an editor versus whatever tradeoffs a GUI has to make to stay performant, make use of screen space, etc. One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.
- reificator 9y ago
  > committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.
  - theptip 9y ago
    `git add -p` adds by the hunk, which is a unit of quantization bigger than a line. E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk". (Waiting for someone to chime in with how to split a hunk and change my life).
    - YoyoyoPCP 9y ago
      You use the 'e' option which allows you to edit the hunk. Remove the minus sign or the entire line with a '+'
      - deleted 9y ago
        [deleted]
emodendroket 9y ago
Which do you use? I'm generally pro-GUI (I love Postman, for instance, and don't use curl much) but my experience with git GUIs has been that they were kind of half-baked and will not do what I expected, leaving me with a difficult-to-understand mess to clean up.
ashelmire 9y ago
Git is, imo, way too simple to require a gui. How long is it taking you and your coworkers to make commits? git commit -am "message" (or add the files you want with git add, then commit); git push; git pr -m "message". The longest part of that is coming up with a good commit message. A gui isn't going to stop people from making mistakes because the mistakes aren't from complexity of the command line, they are from committing things you shouldn't, which will happen regardless of whether or not you use a gui.
- quicklyfrozen 9y ago
  For me, using a GUI makes it much less likely I'll commit the wrong changes as I can quickly review each staged file across the entire tree before committing, and also see if there are unstaged changes (including new files which was often the bane of an SVN workflow) which need to be included. I typically use git gui to commit changes, the cli for other operations, and occasionally source tree to visualize branches and compare with remote repos.
deleted 9y ago
[deleted]
Balero 9y ago
Additionally you can always use the command line if you need to. I use a GUI for 99% of what I do, then use the CLI for what I need it for.
minitech 9y ago
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Nah, it’s just a lot easier than you make it out to be. GUIs are fine too, but if you read the documentation and don’t just memorize a fixed set of commands there’s nothing dangerous, slow, or inconvenient in going about a standard workflow using the CLI. And yes, lots of people don’t have time for this. Totally okay. Don’t generalize to “anyone who uses the CLI is trying too hard”.
B_612 9y ago
The Git UI that comes with intelij can do all the essentials git statements and has a console that logs everything it is doing. And you can also learn useful things by reading the console sometimes. There is no magic.
dlwdlw 9y ago
I wouldn't say "anyone" is trying to hard but I have seen a lot of people who immediately disregard guis as soon as they internalize that the cli is more difficult. Reasons include wanting to be "badass" or "smart". Yet many also do not care about how got differs and basically ask "how do I save" and proceed to revolve their entire workflow on a few copy pasted or memorized commands.other they hear how "rebase" is only for "smart" people... On the opposite side gui users can often be unaware of the actual model and instead be working with imperfect internal models with be GUI being a crutch. In both cases there is lack of desire to learn but I'm often more sympathetic to the latter where people want just enough information to do their work well as oppossed to the former who often make things harder than they have to be in all areas and have lost touch with true expertise in favor of appearance of expertise.
foobaw 9y ago
Android Studio has a git UI built-in so it's really useful.
dozzie 9y ago
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or just couldn't be bothered with leaving terminal. I refuse to reach for mouse for any repository operation when everything else I do from console.
nlawalker 9y ago
I've become a big fan of Git Extensions. I like that it doesn't try to layer its own agenda over the Git workflow, shows all the console input/output it uses, and warns me when I'm about to do something stupid, but overall I like it for the same 3 reasons that I like most GUIs: - It's a live dashboard. A GUI gives me live, persistent information organized well on the screen. I appreciate the power of the CLI for accomplishing tasks, but I've never understood how people prefer it when it comes to simply viewing and understanding the state of something. I don't see why I'd want to run a bunch of commands to see stuff scroll by in my format-constrained terminal when I can have a live, all-up view of multiple aspects of a repo all at once, with relevant, context-sensitive commands on whatever I click on. - It's discoverable. Most of what I've learned about git has been through clicking around in Git Extensions. - The structure and organization of the UI helps me to understand how git operates. When I open the "Pull" dialog, for example, the way the controls in the UI are grouped and the kinds of controls that are used help me logically understand what "Pull" can do.
repsak 9y ago
I use https://github.com/jonas/tig https://github.com/jonas/tig for interactive staging and git CLI for everything else. Best of both worlds and I don't have to leave the terminal.
- aglionby 9y ago
  +1, not having to use a mouse is great. I also use zsh's inbuilt git aliases [0] which I can't recommend enough -- I've found using git CLI without them a pain now that I'm used to them. These together have me productive and happy. [0] https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git
  - barbs 9y ago
    Tip for new tig-players: whilst you can use tig perfectly fine with just the keyboard, it does support using the mouse. Just add `set mouse = yes` to `~/.tigrc` :)
zxy_xyz 9y ago
I use the CLI because I don't currently work on any group projects.
lambda 9y ago
I'd consider myself an expert on Git, and I use a GUI of sorts for the vast majority of my Git work: Magit in Emacs. It has many of the advantages that you describe; makes it easier to get an overview of what's going on, makes it easier to stage individual files, folder, lines of code, hunks, etc. There are a couple of cases in which I need to fall back to the Git command line, but it's not very often, and I do find it substantially improves my life.
machiaweliczny 9y ago
On mac I can recommend Gitup. It's fast and easy. Also vs code has quite nice git integration. I just use it for making commits though. Everything else is faster from CLI.
chiefalchemist 9y ago
Which Git GUI are you using? The GUI is said to be a major leap forward in human conputer usage, in the context the CLI just strikes me as either (elitist?) jargon, or brogrammer bravado. In either case, not really a step forward but certain macho. I still don't get it.
chis 9y ago
I’m a big fan of Gitkraken. Great for doing common actions in one click, and graphically viewing history. It’s crazy how negatively people judge me for using it though. It’s like telling someone I prefer Microsoft Word as my IDE.
collinmanderson 9y ago
Which GUI do you use?
drdrey 9y ago
It doesn't have to be an exclusive or. I use the CLI for most things, but a GUI when it makes sense (like you mentioned, staging specific hunks). I find that for the most part, my CLI workflow is so straightforward I rarely get in an "oh shit" moment: git pull, git co -b featurebranch, a series of git ci -av, and a git push to open a pull request.
inferiorhuman 9y ago
Once upon a time I found a git GUI that I liked (SourceTree). Then Atlassian bought it and pushed their cloud nonsense on me so hard that I just gave up and reverted back to the command line. Eventually I bought the O'Reilly book and figured out how to do the neat things that SourceTree would let me do. Only this time the GUI wouldn't get borked while trying to stage individual lines. I haven't looked back because I haven't found the need.
marssaxman 9y ago
Past experience with GUI frontends and other sorts of simplifying interfaces for version control tools has left me extremely reluctant to use anything more than git's out-of-the-box command line, despite its execrably wretched, unlearnable inconsistency. When things don't make sense with git, I can at least compare notes with coworkers, or search the web and find many discussions where other people have been similarly confused, and received useful advice. If I'm using some custom frontend interface, on the other hand, there are inevitably going to be situations it doesn't handle where I have to fall back to the command line, which I won't remember anything about because I will not have been using it, nobody else on my team is likely to be familiar with the tools I'm using, and discussions on the web are likely to be scarce. Better to just absorb the ongoing pain of git's terrible interface for day-to-day tasks so that I'm not completely hosed when things inevitably go wrong.
chuckdries 9y ago
Seconded for a GUI. I've been using gitkraken for almost a year now, never looked back. (full disclosure: as of last week I actually work for the company behind gitkraken but I started using it far before I realized they were local)
crescentfresh 9y ago
There's a git GUI?? Seriously though, I'm somewhat new to git and any problem I come across (which are many as a new learner) are solved with command line options. I'm not even familiar with the best GUI options out there and have been trying to learn what seemed to be the "standard" way of git'ing.
kendallpark 9y ago
I use a git GUI for staging commits, but the CLI + text editor for everything else (and no aliases). The CLI is universal--I can go to another dev's computer and get them out of rebase hell without learning their particular git GUI interface. Knowing the CLI by heart is also useful if you ever have to use git server side through SSH. I have found that the CLI fits into my workflow better than the GUI for everything except staging.
TomK32 9y ago
I always do `git add --patch`, it's very precise and I can edit lines before staging them. I really don't see why someone would work without it (or a GUI).
pkamb 9y ago
In addition to better staging and committing, I love my git GUI for allowing me to easily see and work with every past commit. Right click on any commit and I can create a new branch there, copy the SHA, do a mixed reset to that location, rebase on it, etc. SO much easier to visualize the actual tree of commits you're working with. I'm sure some people do do all that from the command line. But every CLI coworker of mine has really only known the basics of branching and committing. The GUI unlocks the repo and all of its branches and commits as something you can play with and explore.
qaq 9y ago
Which git GUI are you using?
rectangletangle 9y ago
I've tried out a few different GIT GUIs, and never really took to any of them. Settled for using the CLI + many BASH aliases. Anything I do frequently gets a concise alias to minimize typing. I have relatively short fingers, and I'm admittedly a pretty poor typist, so I really emphasize the concise part. Pretty much all the aliases are write only code. I do this for pretty much every other complex CLI application too, e.g., Docker, Heroku, AWS. A little abstraction really speeds up using the CLI. Aliases are my favorite feature of BASH, I think they've saved me literally months of typing at this point in my life. Here's a few handy ones: alias currentbranch='git rev-parse --abbrev-ref HEAD' alias gpush='git push origin $(currentbranch)' alias gsync='git pull origin $(currentbranch)' alias ga='git add -A' alias gc='git checkout' alias gcm='git commit -m' alias gca='git commit --amend' # and my personal favorite (list recent branches) alias gb='git for-each-ref --sort=-committerdate refs/heads/ --format="%(HEAD) %(color:yellow)%(refname:short)%(color:reset)" | head -n 20'
- tylerhou 9y ago
  My version of gsync is `git pull --rebase origin ${currentbranch}`, since I hate having random merge commits.
outworlder 9y ago
"- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow." "- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)" Do you mean that as "not committed", or "not pushed"? If you mean not committed, then why is it a good thing? You should be committing often. Then you push after you are satisfied. It is much easier to revert mistakes that way.
hyperpallium 9y ago
So... which git GUI are you using?
justbaker 9y ago
I’ve only seen the opposite effect in practice. My odd look as well.
sb8244 9y ago
I'm in such agreement here. I often see files that clearly shouldn't have been committed. I always bring up using Sourcetree or something else, but everyone seems to think that it's okay the way it is. I can't force it on them and to each their own. It is really frustrating though, because there's this stigma against using a git GUI, but the end results of using one are (in my experience) significantly better.
MaulingMonkey 9y ago
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. I've suffered a lot of git GUI bugs. The admittedly large repositories I sometimes deal with cause things to hang and stall, breaking my flow. I keep filing bug reports - truncated diffs because new files were "too large" (presumably someone trying to fix the hang and stall issue), a client that only renders the top half of the window consistently when on a portrait 4K monitor, etc. The git CLI is simply second nature enough to me at this point that waiting for a GUI to load, refresh, etc. is rarely faster. It does happen, but it's not the common case. Getting a good summary of a set of changes is sometimes one of them. Picking individual hunks/lines is sometimes another - although I prefer to commit with such frequency when using git, that it's extremely rare I have changes that belong in different commits. Then, looking at perforce, I'm finding more and more cases where I'm dropping out of P4V and into command line tools. Any kind of mass move/edit seems easier to do through the command line. Command line diffs were way easier to review than P4V's file based diff interface when I had changes involving 1 or 2 line tweaks spread across dozens to hundreds of files (such as verifying function rename changelists didn't accidentally pick up other changes.) I think anyone who's swayed by the beauty of a git GUI has much more patience than me. "Sourcetree (Not Responding)" - I typed this out while waiting for my Visual Rust tab to focus. Euhg. I could've made a commit from the command line in that amount of time.
firemelt 9y ago
What git gui? Git kraken?

lillesvin 9y ago

My biggest issue with a GUI is that most that I've seen introduce new terms for various stuff, e.g. "sync" in VS Code, or "revert commit" (in Source Tree maybe?) — there's no Git command called "sync" or "revert", so I'm not immediately sure what they do. In a CLI I know exactly what's happening. That's just my opinion though. If people feel comfortable working in a GUI all the more power to them.

autarch 9y ago
Git does have a revert command.
- lillesvin 9y ago
  Yeah, my bad. Must've been "reverse" then. I just remember the revert/reverse dichotomy.
  - lttlrck 9y ago
    Or perhaps it called revert but it wasn’t doing a git revert, it was doing a git checkout to simulate an SVN revert... I’ve seen this in at least one GUI. That kind of crap just makes it harder to unwind problems when things go wrong and to learn the tool.
bootcampjs 9y ago
I work with a lot of people who have no idea how git actually works and it is infuriating. They all use the git desktop program, and almost every time I get called over to help, it’s because they didn’t sync or refresh or whatever the hell it does. If you don’t have a good mental model for git, you’re gonna have a bad time.
- lhabjane 9y ago
  Second this. I was one of those people that needed help when I was learning git. Went full CLI after that and never looked back.
joonoro 9y ago
I like Magit because it doesn't try to hide git while still giving all the advantages GP mentioned https://magit.vc/ https://magit.vc/
Alupis 9y ago
> no Git command called ... "revert" Maybe not in the way Source Tree uses it, but there certainly is[1]! I've had to use it a few times. > git-revert - Revert some existing commits [1] https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert
- lillesvin 9y ago
  My bad, then it was "reverse" in Source Tree (or whatever it was).

mmmpop 9y ago

> I think anyone who uses the CLI is either trying too hard Why do you think it's okay to share this opinion?

lwansbrough 9y ago
Because this is a forum and nothing I say matters.
Angostura 9y ago
What makes you think it is not?
- Gracana 9y ago
  Because it's rude and antagonistic and it compels a lot of people to post to defend themselves. It's classic trolling.
- mmmpop 9y ago
  It's not constructive, who cares what you think about CLI users? The fact I'm being downvoted says a lot about the state of this forum.
  - falsedan 9y ago
    Your comment was also trolling: I would have avoided the leading question and just commented on the probable negative interpretation the some CLI users might make of the comment.
ksk 9y ago
The problem of course is the question - What gives anyone a right to do anything? What gives you the right to police the comments? What gives me the right to question your questioning? Meta-discussions always get sidetracked..

emeraldd 9y ago

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

welly 9y ago
If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.
- Ajedi32 9y ago
  Git Kraken isn't FOSS. The site says "Free for non-commercial use", and AFAIK the source isn't available anywhere. I think maybe the term you're looking for is "freeware"?
  - welly 9y ago
    Ah, you're quite right. I was under the impression it was FOSS - I used it a while ago, preferred Tower and so went back to that.
- mistersquid 9y ago
  I second your recommendation of Tower. About a year ago, I made a comment right here on HN singing Tower's praise names. [0] It's impossible to sing those names loudly enough. [0] https://news.ycombinator.com/item?id=12677542
- shagie 9y ago
  Apparently, there is now also a windows version. https://www.git-tower.com/windows https://www.git-tower.com/windows
  - GFischer 9y ago
    Thanks, I had disregarded Tower until I saw your comment :)

Cthulhu_ 9y ago

I don't trust GUI clients; it's easy to not be able to discern the current status, easy to just commit all changes, some of the clients don't respect the pre-push hook, and I've seen other colleagues who have no clue what they're actually doing end up mixing pull and pull --rebase, somehow managing to make duplicate commits with slightly different contents and not having a clue what's going on. Don't use clients if you don't even understand the basic git workflows. And those usually don't support the advanced oh shit situations this article is about.

lwansbrough 9y ago
> it's easy to not be able to discern the current status Probably a failure of whatever UI you're using. I manage just fine. The common statement from CLI types is that "it's just whatever you're better at using" which is true conceptually, but practically, again, CLI users make more mistakes either from fat fingers or lack of understanding of git. Understanding git conceptually from a UI point of view is easy. You don't even have to have a full understanding of git to be effective at using it, if the UI is good. I'm shit with the git CLI, but I understand what git is doing. Yes it's easy to do dumb shit in a GUI, the same is true for CLI. In fact, it's less likely that there'd be a button for doing something dumb than it is that a git novice would find some command on StackOverflow and attempt to use it without fully understanding the ramifications of it.

rhodysurf 9y ago

For the most part using git is like five commands and it is definitely fast to use them from the command line if you have some sort of git understanding

rcxdude 9y ago

I've felt a good GUI would make using git far more intuitive, but I've yet to find a good one. They all seem to fail on one front or another (too hard to use, don't expose enough functionality, attempt to enforce one workflow, aren't available on platforms I want, are slow/resource hogs). Usually I use the included gitk to view the repo, and the CLI to manipulate it.

deleted 9y ago
[deleted]

aschampion 9y ago

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

loup-vaillant 9y ago
A well made GUI conveys those semantics more clearly than the default command line interface. Automation is easier from the CLI, but I wouldn't be surprised if a GUI turned out to be best for manual interactions. (Note: I use the CLI almost exclusively.)
cookiecaper 9y ago
Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.
- The5thElephant 9y ago
  The counter argument is that if you make an error using the CLI, you end up spending more time fixing it than if you just had the GUI open and watching your repo already, and simply switch to it when you need to commit/push.
neves 9y ago
Conflict resolution in a GUI with 3 way merge really beats out a command line.
The5thElephant 9y ago
Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well). Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users. Sometimes dev obsession with tool purity does more damage than good.

swalsh 9y ago

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do it. The GUI get's in my way.

MonkeyIsNull 9y ago
> I'm not 100% sure what's going on under the covers. This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.
- ninkendo 9y ago
  GitHub's GUI is the worst. It has a "sync" button. As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to the CLI.
  - emodendroket 9y ago
    It just pushes the current branch afaik.
    - michaelmior 9y ago
      So it never pulls updates on the remote? That seems like pretty unexpected behaviour.
      - emodendroket 9y ago
        It pulls and then pushes, I guess I should say, but I was considering "pulls and..." part of the push operation.

sigi45 9y ago

I work very well on a cli. I can do partial adds faster than you and don't had any 'oh shit' moments for a few years. I do not care if someone is using a gui. My takeaway: - If i can use git on an cli, i can use git on any server with an cli. I do need this for when i use git on my ansible maschine or on my home media server or when doing something with build infrastructure (jenkins -> git -> cli)

deleted 9y ago

[deleted]

Pxtl 9y ago

I use both - to me the big advantage of getting used to GIT CLI is that you learn the tools to handle uncommon operations and automate tasks, which the GUI doesn't give you. When you need to start piping stuff through grep, for example.

cytzol 9y ago
GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.
- Pxtl 9y ago
  We have a naming convention that feature branches are named "feature-[descriptionOfFeature]" here and I wanted to bulk-delete all the merged feature branches that developers had left dangling, without killing the release branches and the like. Grepping helped there. Like I said, super-rare situation.

madeofpalk 9y ago

I've found my sweet spot is using both a GUI (Github app, to be specific) and a CLI. GUI for partial commits and reviewing my change, and then command line for basically everything else (merge, checkout, branch, etc).

deleted 9y ago

[deleted]

CruiseDevice 9y ago

I don't know how much difference does it make using gui or cli. When i was interviwed for my first job i was asked questions on git. And they asked if i use gui or cli.I think they wanted to know if i really know how to use git through cli. I never used gui for git, maybe i will use in the future. I think Ohsitgit is a good resource which i was trying to find on internet for so long.

dasil003 9y ago

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks. I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split. However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don't want to use whatever shitty editor your tool has in it, I want to use vim with syntax highlighting so I can properly format my commit messages. Even something as simple as viewing a full commit is faster in the CLI because you can just pipe it to less or send it to an editor versus whatever tradeoffs a GUI has to make to stay performant, make use of screen space, etc. One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

reificator 9y ago
> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.
- theptip 9y ago
  `git add -p` adds by the hunk, which is a unit of quantization bigger than a line. E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk". (Waiting for someone to chime in with how to split a hunk and change my life).
  - YoyoyoPCP 9y ago
    You use the 'e' option which allows you to edit the hunk. Remove the minus sign or the entire line with a '+'
    - deleted 9y ago
      [deleted]

emodendroket 9y ago

Which do you use? I'm generally pro-GUI (I love Postman, for instance, and don't use curl much) but my experience with git GUIs has been that they were kind of half-baked and will not do what I expected, leaving me with a difficult-to-understand mess to clean up.

ashelmire 9y ago

Git is, imo, way too simple to require a gui. How long is it taking you and your coworkers to make commits? git commit -am "message" (or add the files you want with git add, then commit); git push; git pr -m "message". The longest part of that is coming up with a good commit message. A gui isn't going to stop people from making mistakes because the mistakes aren't from complexity of the command line, they are from committing things you shouldn't, which will happen regardless of whether or not you use a gui.

quicklyfrozen 9y ago
For me, using a GUI makes it much less likely I'll commit the wrong changes as I can quickly review each staged file across the entire tree before committing, and also see if there are unstaged changes (including new files which was often the bane of an SVN workflow) which need to be included. I typically use git gui to commit changes, the cli for other operations, and occasionally source tree to visualize branches and compare with remote repos.

deleted 9y ago

[deleted]

Balero 9y ago

Additionally you can always use the command line if you need to. I use a GUI for 99% of what I do, then use the CLI for what I need it for.

minitech 9y ago

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Nah, it’s just a lot easier than you make it out to be. GUIs are fine too, but if you read the documentation and don’t just memorize a fixed set of commands there’s nothing dangerous, slow, or inconvenient in going about a standard workflow using the CLI. And yes, lots of people don’t have time for this. Totally okay. Don’t generalize to “anyone who uses the CLI is trying too hard”.

B_612 9y ago

The Git UI that comes with intelij can do all the essentials git statements and has a console that logs everything it is doing. And you can also learn useful things by reading the console sometimes. There is no magic.

dlwdlw 9y ago

I wouldn't say "anyone" is trying to hard but I have seen a lot of people who immediately disregard guis as soon as they internalize that the cli is more difficult. Reasons include wanting to be "badass" or "smart". Yet many also do not care about how got differs and basically ask "how do I save" and proceed to revolve their entire workflow on a few copy pasted or memorized commands.other they hear how "rebase" is only for "smart" people... On the opposite side gui users can often be unaware of the actual model and instead be working with imperfect internal models with be GUI being a crutch. In both cases there is lack of desire to learn but I'm often more sympathetic to the latter where people want just enough information to do their work well as oppossed to the former who often make things harder than they have to be in all areas and have lost touch with true expertise in favor of appearance of expertise.

foobaw 9y ago

Android Studio has a git UI built-in so it's really useful.

dozzie 9y ago

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or just couldn't be bothered with leaving terminal. I refuse to reach for mouse for any repository operation when everything else I do from console.

nlawalker 9y ago

I've become a big fan of Git Extensions. I like that it doesn't try to layer its own agenda over the Git workflow, shows all the console input/output it uses, and warns me when I'm about to do something stupid, but overall I like it for the same 3 reasons that I like most GUIs: - It's a live dashboard. A GUI gives me live, persistent information organized well on the screen. I appreciate the power of the CLI for accomplishing tasks, but I've never understood how people prefer it when it comes to simply viewing and understanding the state of something. I don't see why I'd want to run a bunch of commands to see stuff scroll by in my format-constrained terminal when I can have a live, all-up view of multiple aspects of a repo all at once, with relevant, context-sensitive commands on whatever I click on. - It's discoverable. Most of what I've learned about git has been through clicking around in Git Extensions. - The structure and organization of the UI helps me to understand how git operates. When I open the "Pull" dialog, for example, the way the controls in the UI are grouped and the kinds of controls that are used help me logically understand what "Pull" can do.

repsak 9y ago

I use https://github.com/jonas/tig https://github.com/jonas/tig for interactive staging and git CLI for everything else. Best of both worlds and I don't have to leave the terminal.

aglionby 9y ago
+1, not having to use a mouse is great. I also use zsh's inbuilt git aliases [0] which I can't recommend enough -- I've found using git CLI without them a pain now that I'm used to them. These together have me productive and happy. [0] https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git
- barbs 9y ago
  Tip for new tig-players: whilst you can use tig perfectly fine with just the keyboard, it does support using the mouse. Just add `set mouse = yes` to `~/.tigrc` :)

zxy_xyz 9y ago

I use the CLI because I don't currently work on any group projects.

lambda 9y ago

I'd consider myself an expert on Git, and I use a GUI of sorts for the vast majority of my Git work: Magit in Emacs. It has many of the advantages that you describe; makes it easier to get an overview of what's going on, makes it easier to stage individual files, folder, lines of code, hunks, etc. There are a couple of cases in which I need to fall back to the Git command line, but it's not very often, and I do find it substantially improves my life.

machiaweliczny 9y ago

On mac I can recommend Gitup. It's fast and easy. Also vs code has quite nice git integration. I just use it for making commits though. Everything else is faster from CLI.

chiefalchemist 9y ago

Which Git GUI are you using? The GUI is said to be a major leap forward in human conputer usage, in the context the CLI just strikes me as either (elitist?) jargon, or brogrammer bravado. In either case, not really a step forward but certain macho. I still don't get it.

chis 9y ago

I’m a big fan of Gitkraken. Great for doing common actions in one click, and graphically viewing history. It’s crazy how negatively people judge me for using it though. It’s like telling someone I prefer Microsoft Word as my IDE.

collinmanderson 9y ago

Which GUI do you use?

drdrey 9y ago

It doesn't have to be an exclusive or. I use the CLI for most things, but a GUI when it makes sense (like you mentioned, staging specific hunks). I find that for the most part, my CLI workflow is so straightforward I rarely get in an "oh shit" moment: git pull, git co -b featurebranch, a series of git ci -av, and a git push to open a pull request.

inferiorhuman 9y ago

Once upon a time I found a git GUI that I liked (SourceTree). Then Atlassian bought it and pushed their cloud nonsense on me so hard that I just gave up and reverted back to the command line. Eventually I bought the O'Reilly book and figured out how to do the neat things that SourceTree would let me do. Only this time the GUI wouldn't get borked while trying to stage individual lines. I haven't looked back because I haven't found the need.

marssaxman 9y ago

Past experience with GUI frontends and other sorts of simplifying interfaces for version control tools has left me extremely reluctant to use anything more than git's out-of-the-box command line, despite its execrably wretched, unlearnable inconsistency. When things don't make sense with git, I can at least compare notes with coworkers, or search the web and find many discussions where other people have been similarly confused, and received useful advice. If I'm using some custom frontend interface, on the other hand, there are inevitably going to be situations it doesn't handle where I have to fall back to the command line, which I won't remember anything about because I will not have been using it, nobody else on my team is likely to be familiar with the tools I'm using, and discussions on the web are likely to be scarce. Better to just absorb the ongoing pain of git's terrible interface for day-to-day tasks so that I'm not completely hosed when things inevitably go wrong.

chuckdries 9y ago

Seconded for a GUI. I've been using gitkraken for almost a year now, never looked back. (full disclosure: as of last week I actually work for the company behind gitkraken but I started using it far before I realized they were local)

crescentfresh 9y ago

There's a git GUI?? Seriously though, I'm somewhat new to git and any problem I come across (which are many as a new learner) are solved with command line options. I'm not even familiar with the best GUI options out there and have been trying to learn what seemed to be the "standard" way of git'ing.

kendallpark 9y ago

I use a git GUI for staging commits, but the CLI + text editor for everything else (and no aliases). The CLI is universal--I can go to another dev's computer and get them out of rebase hell without learning their particular git GUI interface. Knowing the CLI by heart is also useful if you ever have to use git server side through SSH. I have found that the CLI fits into my workflow better than the GUI for everything except staging.

TomK32 9y ago

I always do `git add --patch`, it's very precise and I can edit lines before staging them. I really don't see why someone would work without it (or a GUI).

pkamb 9y ago

In addition to better staging and committing, I love my git GUI for allowing me to easily see and work with every past commit. Right click on any commit and I can create a new branch there, copy the SHA, do a mixed reset to that location, rebase on it, etc. SO much easier to visualize the actual tree of commits you're working with. I'm sure some people do do all that from the command line. But every CLI coworker of mine has really only known the basics of branching and committing. The GUI unlocks the repo and all of its branches and commits as something you can play with and explore.

qaq 9y ago

Which git GUI are you using?

rectangletangle 9y ago

I've tried out a few different GIT GUIs, and never really took to any of them. Settled for using the CLI + many BASH aliases. Anything I do frequently gets a concise alias to minimize typing. I have relatively short fingers, and I'm admittedly a pretty poor typist, so I really emphasize the concise part. Pretty much all the aliases are write only code. I do this for pretty much every other complex CLI application too, e.g., Docker, Heroku, AWS. A little abstraction really speeds up using the CLI. Aliases are my favorite feature of BASH, I think they've saved me literally months of typing at this point in my life. Here's a few handy ones: alias currentbranch='git rev-parse --abbrev-ref HEAD' alias gpush='git push origin $(currentbranch)' alias gsync='git pull origin $(currentbranch)' alias ga='git add -A' alias gc='git checkout' alias gcm='git commit -m' alias gca='git commit --amend' # and my personal favorite (list recent branches) alias gb='git for-each-ref --sort=-committerdate refs/heads/ --format="%(HEAD) %(color:yellow)%(refname:short)%(color:reset)" | head -n 20'

tylerhou 9y ago
My version of gsync is `git pull --rebase origin ${currentbranch}`, since I hate having random merge commits.

outworlder 9y ago

"- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow." "- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)" Do you mean that as "not committed", or "not pushed"? If you mean not committed, then why is it a good thing? You should be committing often. Then you push after you are satisfied. It is much easier to revert mistakes that way.

hyperpallium 9y ago

So... which git GUI are you using?

justbaker 9y ago

I’ve only seen the opposite effect in practice. My odd look as well.

sb8244 9y ago

I'm in such agreement here. I often see files that clearly shouldn't have been committed. I always bring up using Sourcetree or something else, but everyone seems to think that it's okay the way it is. I can't force it on them and to each their own. It is really frustrating though, because there's this stigma against using a git GUI, but the end results of using one are (in my experience) significantly better.

MaulingMonkey 9y ago

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. I've suffered a lot of git GUI bugs. The admittedly large repositories I sometimes deal with cause things to hang and stall, breaking my flow. I keep filing bug reports - truncated diffs because new files were "too large" (presumably someone trying to fix the hang and stall issue), a client that only renders the top half of the window consistently when on a portrait 4K monitor, etc. The git CLI is simply second nature enough to me at this point that waiting for a GUI to load, refresh, etc. is rarely faster. It does happen, but it's not the common case. Getting a good summary of a set of changes is sometimes one of them. Picking individual hunks/lines is sometimes another - although I prefer to commit with such frequency when using git, that it's extremely rare I have changes that belong in different commits. Then, looking at perforce, I'm finding more and more cases where I'm dropping out of P4V and into command line tools. Any kind of mass move/edit seems easier to do through the command line. Command line diffs were way easier to review than P4V's file based diff interface when I had changes involving 1 or 2 line tweaks spread across dozens to hundreds of files (such as verifying function rename changelists didn't accidentally pick up other changes.) I think anyone who's swayed by the beauty of a git GUI has much more patience than me. "Sourcetree (Not Responding)" - I typed this out while waiting for my Visual Rust tab to focus. Euhg. I could've made a commit from the command line in that amount of time.

firemelt 9y ago

What git gui? Git kraken?