I'd been using git for a couple months on a project on my own with no problems. Too bad the Mercurial back-end is so slow. The CLI usability completely falls apart when you start rebasing, merging and cleaning up WIP commits.Ī tool like Mercurial proves that DVCS systems do not have to have a confusing CLI, in all the years I've been using it, I've never felt compelled to use a GUI. Obviously when you are only pulling and pushing from master, there's not much that can go wrong, but if that's all you do, Subversion would do the trick just as well. Now I'm much happier and actually enjoy working with git. I'm not a GUI person at all, but the times I had to lookup 20 different ways that 'git reset' worked, or had to google what on earth the apparently random combination of words like refspec, remote, origin, branch and non-bare actually meaned have been enough to drive me to a GUI tool. Sure, but that's not really an excuse for git to have such a confusing and possibly destructive command line. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force. > The Unix CLI is far more dangerous than Git. I really didn't get on with GitX, but I don't remember it being a great deal more than git gui and gitk, in the same app, with a fancy OS X-looking interface. gitk, for all its ability to display the history in a useful format, is similarly limited (or designed for a specific purpose, if you prefer). Any time you want to do anything remotely complicated, you need to drop out of git gui and hit the command line. I don't claim to be the sharpest tool in the box.īut anyway, you need have no fear that people won't get forced into using the command line eventually, just because they like git gui. I found git a bit of a mystery until I realised I could see what it was doing this way, and suddenly everything became clear. The command line is much more of an abstraction in this case, I think! - gitk displays the actual tree of this graph that git manipulates, but the command line just prints text ) It's especially illuminating (or I found it so, anyway) to keep gitk -all open as you do merges, rebases, pushes, fetches, etc., refreshing the display after each operation - it makes it very clear what's actually happening. I think denying beginners the GUI is particularly cruel. And you'll really wish you invested the time to learn those underlying CLI commands. Also, have you ever tried using a GUI when SSH'd into a remote server in a pinch? You can't. For the most part, all the git CLI commands port from Mac, Linux and Windows (msysgit). GUIs also aren't always available across platforms, either. They are the foundation for doing your job. There's no excuse for not knowing them intimately. That's why I highlighted in the article that I need two tools to do my development: an editor and version control. If you write code day in day out you SHOULD be comfortable on the command-line. Sure it might be OK for some things like browsing history (GitX) but most GUIs often abstracts away much of the underlying complexity, which is absolutely great if you're a designer without much command-line experience, but absolutely a disservice to your in-depth knowledge as a developer and the tools you rely on every day. I never advocate GUIs as the primary means by which a developer works with version control.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |