7 ms·

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as advanced branch manipulation or hunk selection as with git add -p) are considerably harder with the command line than with GUI tools, simply because the command line doesn't give you a full enough picture of what you're doing.

mrcsparker 12y ago
What git gui do you recommend?
- jammycakes 12y ago
  Atlassian SourceTree mainly. Git Extensions is also good if you need Visual Studio integration, though personally I find it visually a bit harsh.
- chopin 12y ago
  I work much with Java and Eclipse, eGit is a good choice here. I mostly use the history view and the staging view (which lets you add/remove files). For complicated tasks the history view is a very valuable tool which I even use when I prefer to do something on the command line.
timblair 12y ago
That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface. I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVCS from the ground up (i.e. from the command line) ends up with a greater level of understanding. Once you've got that, you can move on to using a GUI to improve your workflow, but with the understanding of exactly what is being abstracted away.
- jammycakes 12y ago
  Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donnas into the bargain. In any case, I'm quite sceptical of the claim that you can teach Git more effectively through the command line alone. Here's why: the two most important concepts to understand before you can properly grok DVCS are (a) that your source history is a key integral part of your workflow and not just a sideshow, and (b) how revisions, changesets and merges relate to each other through the DAG. GUI tools do this very effectively by putting your source history, complete with a graphical view of your revisions, right at the front of your workflow. By contrast, the command line requires you to type git log --graph, effectively relegating it to a sideshow like in the bad old days of Subversion. I can't help getting the impression that learning DVCS through the command line risks you ending up with an understanding of the subject that is fundamentally flawed. You see this in virtually every Git versus Mercurial debate that focuses on which one is better at branching and merging. Most of the arguments that I've seen leave me with the impression that the people who are making them haven't a clue what they're talking about.
  - mbrock 12y ago
    But this isn't really a newbie's guide to using Git, as far as I can tell. There are probably other texts that are more suitable for that purpose. This text was pretty useful for me as a refresher-type thing to clarify the basic data types and inner workings of Git. There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provides graphs and visual means of understanding, and explains how these representations relate to the CLI tools. Very helpful! I don't really agree with your complaint, because it seems like you're just saying "I would prefer to read a different kind of article," which is fine, but it's not a criticism. The argument about "alienating an even larger portion of your reader base" seems spurious; the author can write to whatever target audience they want!
mistermann 12y ago
Sorry for a bit of a Hijack.....anyone care to comment on what is generally considered the best git GUI tool for Windows/Visual Studio?
- voltagex_ 12y ago
  Visual Studio Git Tools in 2012 and 2013, and then Atlassian SourceTree for the stuff VS can't do (VS's integration is based on libgit2 and has limitations)
- thomaslangston 12y ago
  Sourcetree has been my favorite, followed by the default GUI installed from the git-scm.com. I've not been a fan of the VS extension because of performance (a want NCrunch and Resharper to have all my free cycles).
- angersock 12y ago
  TortoiseGit is pretty decent, though it doesn't have VS integration.
- gnoway 12y ago
  A lot of our developers use GitExtensions and like it. I don't personally like or use it, so I am not sure why it is preferred.
wldlyinaccurate 12y ago
Author here. This is something I hear a lot, and I agree with it to a certain extent, but I purposely left out any mention of GUIs for a few reasons: 1. The guide is intended for people who want to take a look "under the hood". This is really difficult to do through GUIs, which tend to hide all of the implementation details. 2. As a child comment mentioned, even if I include GUIs in the guide, I can't possibly cover all of them. This just confuses things for people who use GUI X when the guide only talks about GUI Y and Z. 3. It's much easier to write the guide using CLI examples. I wrote this over the weekend; I don't think I would have completed anywhere near as much of it if I had to keep taking screenshots, cropping them, uploading them, etc. Besides, there are already plenty of other guides that talk about "how to use Git", "how to use GUI X to do Git feature Y". I wouldn't want to detract from the main goal of this guide which is to give people who are already comfortable with Git that extra push to "get" how Git models and interacts with your repository.
- thomaslangston 12y ago
  Thanks for posting this guide. I hope to read it soon. Some thoughts on your response: 1) Sometimes the GUI illuminates and the console obfuscates. Logs and history are a lot easier for developers to understand in my experience from a GUI. 2) I'd suggest only using the included GIT GUI that comes with the download from git-scm.com. It is simple enough that it should map easily to another GUI, plus if they aren't using an embedded git everyone should already have it installed.
- dahart 12y ago
  Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI. But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were. And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology. Adding menu options with the names of things git does makes git slightly more discoverable, but not much easier to understand. For better or worse, I think understanding git from the command line point of view is (currently) critical to a deep understanding of git, even if you're using a git GUI.
MattBearman 12y ago
I had the opposite experience - coming from tortoise SVN, I tried a few GUIs for Git, but I never really got to grips with git until I started using the command line, and now I can't imagine going back to a GUI.
nahname 12y ago
Why not write one?
- jammycakes 12y ago
  The thought has occurred to me. Just never got round to it, that's all...
grannyg00se 12y ago
Try this http://pcottle.github.io/learnGitBranching/?NODEMO http://pcottle.github.io/learnGitBranching/?NODEMO It's command line, but it's interactive and visual. Start off by typing the command `levels` into the prompt at the bottom left.

mrcsparker 12y ago

What git gui do you recommend?

jammycakes 12y ago
Atlassian SourceTree mainly. Git Extensions is also good if you need Visual Studio integration, though personally I find it visually a bit harsh.
chopin 12y ago
I work much with Java and Eclipse, eGit is a good choice here. I mostly use the history view and the staging view (which lets you add/remove files). For complicated tasks the history view is a very valuable tool which I even use when I prefer to do something on the command line.

timblair 12y ago

That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface. I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVCS from the ground up (i.e. from the command line) ends up with a greater level of understanding. Once you've got that, you can move on to using a GUI to improve your workflow, but with the understanding of exactly what is being abstracted away.

jammycakes 12y ago
Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donnas into the bargain. In any case, I'm quite sceptical of the claim that you can teach Git more effectively through the command line alone. Here's why: the two most important concepts to understand before you can properly grok DVCS are (a) that your source history is a key integral part of your workflow and not just a sideshow, and (b) how revisions, changesets and merges relate to each other through the DAG. GUI tools do this very effectively by putting your source history, complete with a graphical view of your revisions, right at the front of your workflow. By contrast, the command line requires you to type git log --graph, effectively relegating it to a sideshow like in the bad old days of Subversion. I can't help getting the impression that learning DVCS through the command line risks you ending up with an understanding of the subject that is fundamentally flawed. You see this in virtually every Git versus Mercurial debate that focuses on which one is better at branching and merging. Most of the arguments that I've seen leave me with the impression that the people who are making them haven't a clue what they're talking about.
- mbrock 12y ago
  But this isn't really a newbie's guide to using Git, as far as I can tell. There are probably other texts that are more suitable for that purpose. This text was pretty useful for me as a refresher-type thing to clarify the basic data types and inner workings of Git. There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provides graphs and visual means of understanding, and explains how these representations relate to the CLI tools. Very helpful! I don't really agree with your complaint, because it seems like you're just saying "I would prefer to read a different kind of article," which is fine, but it's not a criticism. The argument about "alienating an even larger portion of your reader base" seems spurious; the author can write to whatever target audience they want!

mistermann 12y ago

Sorry for a bit of a Hijack.....anyone care to comment on what is generally considered the best git GUI tool for Windows/Visual Studio?

voltagex_ 12y ago
Visual Studio Git Tools in 2012 and 2013, and then Atlassian SourceTree for the stuff VS can't do (VS's integration is based on libgit2 and has limitations)
thomaslangston 12y ago
Sourcetree has been my favorite, followed by the default GUI installed from the git-scm.com. I've not been a fan of the VS extension because of performance (a want NCrunch and Resharper to have all my free cycles).
angersock 12y ago
TortoiseGit is pretty decent, though it doesn't have VS integration.
gnoway 12y ago
A lot of our developers use GitExtensions and like it. I don't personally like or use it, so I am not sure why it is preferred.

wldlyinaccurate 12y ago

Author here. This is something I hear a lot, and I agree with it to a certain extent, but I purposely left out any mention of GUIs for a few reasons: 1. The guide is intended for people who want to take a look "under the hood". This is really difficult to do through GUIs, which tend to hide all of the implementation details. 2. As a child comment mentioned, even if I include GUIs in the guide, I can't possibly cover all of them. This just confuses things for people who use GUI X when the guide only talks about GUI Y and Z. 3. It's much easier to write the guide using CLI examples. I wrote this over the weekend; I don't think I would have completed anywhere near as much of it if I had to keep taking screenshots, cropping them, uploading them, etc. Besides, there are already plenty of other guides that talk about "how to use Git", "how to use GUI X to do Git feature Y". I wouldn't want to detract from the main goal of this guide which is to give people who are already comfortable with Git that extra push to "get" how Git models and interacts with your repository.

thomaslangston 12y ago
Thanks for posting this guide. I hope to read it soon. Some thoughts on your response: 1) Sometimes the GUI illuminates and the console obfuscates. Logs and history are a lot easier for developers to understand in my experience from a GUI. 2) I'd suggest only using the included GIT GUI that comes with the download from git-scm.com. It is simple enough that it should map easily to another GUI, plus if they aren't using an embedded git everyone should already have it installed.
dahart 12y ago
Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI. But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were. And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology. Adding menu options with the names of things git does makes git slightly more discoverable, but not much easier to understand. For better or worse, I think understanding git from the command line point of view is (currently) critical to a deep understanding of git, even if you're using a git GUI.

MattBearman 12y ago

I had the opposite experience - coming from tortoise SVN, I tried a few GUIs for Git, but I never really got to grips with git until I started using the command line, and now I can't imagine going back to a GUI.

nahname 12y ago

Why not write one?

jammycakes 12y ago
The thought has occurred to me. Just never got round to it, that's all...

grannyg00se 12y ago

Try this http://pcottle.github.io/learnGitBranching/?NODEMO http://pcottle.github.io/learnGitBranching/?NODEMO It's command line, but it's interactive and visual. Start off by typing the command `levels` into the prompt at the bottom left.