21

With the easy experience of TortoiseSVN, I looked at some command line of SVN and it wasn't as easy to use. Does TortoiseGit actually makes Git a lot easier to use, just like TortoiseSVN did for the SVN command line?

nonopolarity
  • 146,324
  • 131
  • 460
  • 740
  • 1
    It's a frontend for git, so its primary task is to make it easier. At least the most common tasks will be a lot of easier, but as with any frontend that is built on top of a command line program, as soon as you need something more special (and git has a lot things like that), the frontend will no longer work. And then you have to use the command line anyway, in which case it might be even harder, given that you get much experience with the command line... – poke Apr 13 '11 at 07:23
  • 2
    If it's anything like tortoiseSVN, I'm sure it makes is better but I've tried a few GUIs for git and have found the command line much more effective if I want to *really* use it. – Noufal Ibrahim Apr 13 '11 at 07:31
  • You could take a look at [SmartGit](http://www.syntevo.com/smartgit/index.html). – Benjol Apr 13 '11 at 10:54
  • You could also have a look, on windows, to the very good and free GUI [GitExtensions](http://code.google.com/p/gitextensions/) and [SourceTree](http://www.sourcetreeapp.com/). If you want a REALLY simple GUI (but without all git features), you could use [GitHub On Windows](http://windows.github.com/) – Philippe Oct 15 '13 at 16:19

2 Answers2

17

I think, you lose a lot of functionality of Git when you use TortoiseGit. From my point of view, TortoiseGit gives the user the feeling of using SVN while the actual back-end is Git.

When I was working with SVN repos, the only client I used was TortoiseSVN. No console at all.

But learning Git was quite console-driven for me, so I use the console to work with Git. There are some use cases when I fire up my TortoiseGit, for example when reading logs or resolving conflicts. But instead of Tortoise, I could also use gitk for that. And — not to forget — TortoiseGit is not the most stable piece of software.

In my opinion, the only right to exist for TortoiseGit is to catch the TortoiseSVN users that are switching to Git: they can stick to their used explorer integration and don't have to learn a new tool when using a new VCS (IMHO, the learning curve of Git is steep enough, so some people might first focus on learning the basics of git before discovering the power of the console). And the point-and-click Windows guys don't have to communicate with their system through a console. That's it.

I share the opinion of Noufal: if you want to use Git, take the console, if you want to play with it, take TortoiseGit.


Edit:
I do respect the work of the TortoiseGit project team that eases transition from SVN to Git for users that used TortoiseSVN before. But in my opinion: to use the full power of Git, you have to start up your Git bash. You can work with Git using TortoiseGit only, but then, you're just scratching the surface of Git.

By the way: the TortoiseGit project description says:

TortoiseGit supports you by regular tasks, such as committing, showing logs, diffing two versions, creating branches and tags, creating patches and so on [...].

So their own view of their project shares mine: TortoiseGit for scratching the surface but you'll need other tools (i.e. the console) to discover the whole beauty of Git.

Community
  • 1
  • 1
eckes
  • 64,417
  • 29
  • 168
  • 201
  • 4
    +1 for the last sentence :) git is a quite powerful tool, but I didnt see any gui tool, that reflects this power in a way, that doesnt makes git look like "just another vcs". – KingCrunch Apr 13 '11 at 12:12
  • On the other hand, why should 'REALLY using git' require you to have to break out the command line? In my experience, the vast majority of the time, the GUI provides everything you need. You should still learn and understand the git workflow, but that doesn't mean the more you know the less you'd want to use Tortoise or any good GUI for that matter. – johnb003 Mar 15 '14 at 03:34
  • 6
    The original answer is 3 years old. TortoiseGit has come a long way and the only missing daily feature I can come up with is line-wise commits. In '11 I did most of my Git-use on the command line while these days I'm happy working in TortoiseGit most of the time. Having most features (Switch/Checkout, Merge, Rebase) integrated in the Git Log window is a big convenience as the visualization TortoiseGit log provides is way better than what the command line has. – Mikko Rantanen Apr 08 '14 at 19:05
  • 1
    @MikkoRantanen: That's 3 years you could have spent learning the commands on the bash... I'm using the command line now for 3 years and **never** found a reason why I would switch over to TortoiseGit. – eckes Apr 08 '14 at 21:01
  • 9
    @eckes: Good for you. However this question is also (or especially) of interest for people who are making the switch from SVN to Git **today**. These people don't have 3 years of command line git experience. Myself I'm perfectly comfortable on the command line, but at the same time I find it harder and harder to really recommend command line use for new Git users on Windows. The gap between the two tools is smaller today than it was 3 years ago, while, as you say, TortoiseGit reduces the learning curve. – Mikko Rantanen Apr 12 '14 at 16:44
16

I don't think there should be any stigma attached to using TortoiseGit in preference to the command line git. After all, if you're developing in Windows then your primary interface with the file system is through Windows Explorer.

TortoiseGit handles the most common use cases: checking out, checking in, diffs, logs, etc. If you find something you need to do that it can't handle then by all means drop back to the command line executable, but for 98% of what you need to do on a daily basis there are tools in TortoiseGit to support you.

In particular, consider the act of committing your latest set of changes. In TortoiseGit, my workflow is as follows. I commit the root folder and get a window listing the changed files. I can then go through these one by one, choosing which changes to commit. Some changes may have been temporary tweaks that need reverting (a simple right-click), some are local overrides that should not be in the repository, some are temporary files that can be safely deleted (again, a right-click), etc. For the rest of them, I always diff the modified files against the versions in the repository (a simple double-click). This is a useful sanity check that you know what you're committing. For example, you can remove any temporary debugging code or add back anything that was temporarily commented out. It also gives you the chance to take a step back and consider the quality of your changes; for example, if you've added a new method but forgotten to add documentation comments you can do it at this stage.

For this sort of workflow, driving everything from a single commit window is a lot simpler than firing off a bunch of separate git commands.

Matthew Strawbridge
  • 19,940
  • 10
  • 72
  • 93
  • 2
    "_if you're developing in Windows then your primary interface with the file system is through Windows Explorer._" Is it? – jwg Jan 04 '13 at 12:50
  • 13
    @jwg Yes, it is :-) – Matthew Strawbridge Jan 04 '13 at 20:46
  • Of course there are crazy people who will use crazy software like Midnight Commander (or something like that), but us sane developers use Explorer on Windows. It's built in - leave command line navigation to use on Unix! – Camilo Martin Jun 04 '13 at 18:12
  • So, when you are writing code, you don't use some sort of IDE, you just look for files using Windows Explorer and open them in notepad? I mean, it's built in right? Leave efficient coding tools for Unix users! – TamaMcGlinn Apr 23 '20 at 14:24