开发者

Does TortoiseGit actually make Git a lot easier to use like TortoiseSVN? [closed]

开发者 https://www.devze.com 2023-02-24 01:04 出处:网络
Closed. This question is opinion-based. It is not currently accepting answers. 开发者_开发技巧 Want to improve this question? Update the question so it can be answered with facts and citati
Closed. This question is opinion-based. It is not currently accepting answers. 开发者_开发技巧

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

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?


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消