I’m a developer of Gitbox – a mac app for Git which makes core concepts easy to understand and work with. In particular, I’m fixing two usability issues: branches and the stage.
Many people do not create additional branches because of a fear: command-line interface does not make it easy to understand where you are. Also, many do not understand what the stage (index) is and why you should “git add” before committing the stuff.
To fix these issues, Gitbox has very simple branch controls which let you always see what branch you are on and where will it push: just two popup lists for the local and remote branches and simple pull/push button in the middle.
The stage is represented by a list of changes with checkboxes showing the staged status. Also, if you simply select some changes and hit the “Commit” button, the selected changes are added to the stage automatically.
Also, instead of showing incomprehensible trees of branches, it shows a difference between currently selected branches right in the history log (local vs. remote or local vs. other local).
The article fails to mention this, but the easiest way to install and update Git on OS X is by using “homebrew”:http://github.com/mxcl/homebrew. It only takes one command to install homebrew; after that, just enter `brew install git` to install Git.
After that, you can update Git to the latest version at any time, just by entering `brew update git`.
Just a recommendation for those inspired by this article: Travis Swicegood’s Pragmatic Version Control Using Git is a thorough practical and conceptual treatment of Git. His follow-along-at-home examples are actually based on a simple website and therefore readily accessible to a web designer/developer audience. He also spends an entire chapter covering the use of Git in shops that already have SVN in place for version control.
Copy & paste the code below to embed this comment.
Al Shaw
@marcel I should have been more specific. If you add a file and commit it right away, yes you’ll be able to just commit -m. However, if you add an untracked file and then make local changes to it, you’ll need to add once again to stage it. But yes, you are correct.
It’s also worth pointing out that you can actually fork, edit code, and do a pull request without ever touching a command line.
The instructions are here
“How to submit a fix to jQuery UI — The Easy Way”:http://blog.jqueryui.com/2010/05/how-to-submit-a-fix-to-jquery-ui-the-easy-way/
but basically you have to realize there is a little `Edit` link in the corner of the file view on Github.
In the last year I’ve been using Bazaar to manage html, css and js. Bazaar is a non-centralised VCS developed by Canonical and used in the development of Ubuntu.
I agree with Linus Torvalds that a distributed revision control has huge advantages over a centralised revision control. The problem is that there are too many popular distributed vcs’s out there. If you join a new team and start a new project, everybody will want to use the tools they are familiar with and in the end you might have to learn a new tool.
I know projects that use Git, but also Bazaar and Mercurial. And there are others… And on the centralised side you have Subversion, CVS…
Compared with Bazaar, the concepts behind git are more complex and it takes longer to learn how to use git than Bazaar. Bazaar can also be used as a centralised VCS.
In theory Git looks like everything we want. We are stugging to impliment it though – we get mysterious error messages when trying to init git on a new machine (windows) or trying to merge. Finding a clear simple guide is difficult and the git UI seems suspect. We are trying to figuer out whats wrong, but lack of a centralised forum is not helping. We have yet to find a good forum. We’d even be happy to host one.
@Osvaldo: There are a lot of DVCSs at the moment, but I think it’s clear that git is in the lead, so I think it’s an easy choice to make as far as deciding which to invest in. And git can be used like a centralised VCS if you wish – after all, look at github.
@sad developer: As far as I’m concerned, either “msysgit”:http://code.google.com/p/msysgit/ or “Cygwin”:http://www.cygwin.com/ are the way to go with git on Windows. msysgit is very straightforward to install, but Cygwin gives you all the other Unix tools should you decide to go further down the Unix/Linux rabbit hole.
I’m the only designer in my office that uses Git. It’s too technical for the average artsy-fartsy type to “get” git. I wish there was “Mindless Git”. For instance, “Dropbox”:dropbox.com does versioning on its synced folders. I know every save gets versioned away in the ionosphere, mindlessly. Mac needs that built-in. Time Machine isn’t frequent — or powerful — enough.
Good article, Al. I’ve been reading about Git for ages and been meaning to get around to trying it and after reading this article (or should I say while), I finally have. Now I’ve just got to start using it. ;)
You’re right, you don’t have to be a code writer to need a tool like this. As a web developer, I’m often creating dated filenames, dated directories, pre, post, active, you name it…just to try and keep up with everything that’s archive, current, and future.
Copy & paste the code below to embed this comment.
Lucas Sandery
I don’t think that’s really getting started. Maybe you like the command line a lot but, for most tasks, Git GUI is sufficient and is far more illustrative of what Git actually does, especially for those new to VCSs.
I love Git and use msysgit every day. I don’t have to use the command line very much to be productive.
I like my favourite bash commands set as (often global) tools in the in the Tools menu. I have stashgit stash save, unstashgit stash pop, great for quickly stopping what you’re doing to do something else then, going back to it without any branching. For regular exporting, I use some variation of git archive—format=zip -9 master > ../latest_version.zip, that one archives adjacent to the repository directory.
Copy & paste the code below to embed this comment.
Dormilich
Mac users that already use “MacPorts”:http://macports.org/ (e.g. if you’re running their Apache/MySQL/PHP/Python ports) will find Git and some applications around Git (e.g. GitX) there as well.
Copy & paste the code below to embed this comment.
xipmix
Thanks so much for this article, I finally clicked on the ‘staging area’ and so much more of git makes sense now.
The key thing was your explanation of how to turn a somewhat tangled set of changes into a sequence of well-organised commits.
The “double-add” discussion with Marcel underlines this nicely – to a new user it would be easier to understand if the initial add was called something like “git-include” (ie include this file in the repository) that auto-committed the change. Then the need for a “git-add” later, if changes were made to the file, would seem natural.
This is the first time I’ve seen (in a lot of reading about git) such a vivid example of what the staging area is good for. I encourage you to try to get this example into the git reference documentation; it’s one every user of a text editor can relate to.
Copy & paste the code below to embed this comment.
benknight
I would imagine what they were thinking with the hot pink was to remind people you can style the selection, being a starter’s kit and all. Regardless it’s still a good example.
17 Reader Comments
Back to the Articleoleganza
I’m a developer of Gitbox – a mac app for Git which makes core concepts easy to understand and work with. In particular, I’m fixing two usability issues: branches and the stage.
Many people do not create additional branches because of a fear: command-line interface does not make it easy to understand where you are. Also, many do not understand what the stage (index) is and why you should “git add” before committing the stuff.
To fix these issues, Gitbox has very simple branch controls which let you always see what branch you are on and where will it push: just two popup lists for the local and remote branches and simple pull/push button in the middle.
The stage is represented by a list of changes with checkboxes showing the staged status. Also, if you simply select some changes and hit the “Commit” button, the selected changes are added to the stage automatically.
Also, instead of showing incomprehensible trees of branches, it shows a difference between currently selected branches right in the history log (local vs. remote or local vs. other local).
Check it out on http://gitboxapp.com/
mathiasbynens
The article fails to mention this, but the easiest way to install and update Git on OS X is by using “homebrew”:http://github.com/mxcl/homebrew. It only takes one command to install homebrew; after that, just enter `brew install git` to install Git.
After that, you can update Git to the latest version at any time, just by entering `brew update git`.
marcel
What’s meant by needing to add a new file twice? In the example below, I add a new file just once and it works fine.
pre.
~/test-repo|master$ touch blah
~/test-repo|master$ git status
# On branch master
# Untracked files:
# (use “git add <file>…” to include in what will be committed)
#
# blah
nothing added to commit but untracked files present (use “git add” to track)
~/test-repo|master$ git add blah
~/test-repo|master$ git commit -m ‘Add blah’
[master f477efd] Add blah
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 blah
~/test-repo|master$ git status
# On branch master
nothing to commit (working directory clean)
karlstolley
Just a recommendation for those inspired by this article: Travis Swicegood’s Pragmatic Version Control Using Git is a thorough practical and conceptual treatment of Git. His follow-along-at-home examples are actually based on a simple website and therefore readily accessible to a web designer/developer audience. He also spends an entire chapter covering the use of Git in shops that already have SVN in place for version control.
Al Shaw
@marcel I should have been more specific. If you add a file and commit it right away, yes you’ll be able to just commit -m. However, if you add an untracked file and then make local changes to it, you’ll need to add once again to stage it. But yes, you are correct.
paul irish
How dare you! :)
Awesome writeup, Al.
It’s also worth pointing out that you can actually fork, edit code, and do a pull request without ever touching a command line.
The instructions are here
“How to submit a fix to jQuery UI — The Easy Way”:http://blog.jqueryui.com/2010/05/how-to-submit-a-fix-to-jquery-ui-the-easy-way/
but basically you have to realize there is a little `Edit` link in the corner of the file view on Github.
Magic. :)
Référencement
Very nice post; detailed. I found it perfect. But could you enlighten me please :
Is Git more interesting than SVN, if so for what kind of project?
Osvaldo
In the last year I’ve been using Bazaar to manage html, css and js. Bazaar is a non-centralised VCS developed by Canonical and used in the development of Ubuntu.
I agree with Linus Torvalds that a distributed revision control has huge advantages over a centralised revision control. The problem is that there are too many popular distributed vcs’s out there. If you join a new team and start a new project, everybody will want to use the tools they are familiar with and in the end you might have to learn a new tool.
I know projects that use Git, but also Bazaar and Mercurial. And there are others… And on the centralised side you have Subversion, CVS…
Compared with Bazaar, the concepts behind git are more complex and it takes longer to learn how to use git than Bazaar. Bazaar can also be used as a centralised VCS.
sad developer
In theory Git looks like everything we want. We are stugging to impliment it though – we get mysterious error messages when trying to init git on a new machine (windows) or trying to merge. Finding a clear simple guide is difficult and the git UI seems suspect. We are trying to figuer out whats wrong, but lack of a centralised forum is not helping. We have yet to find a good forum. We’d even be happy to host one.
skilldrick
@Osvaldo: There are a lot of DVCSs at the moment, but I think it’s clear that git is in the lead, so I think it’s an easy choice to make as far as deciding which to invest in. And git can be used like a centralised VCS if you wish – after all, look at github.
@sad developer: As far as I’m concerned, either “msysgit”:http://code.google.com/p/msysgit/ or “Cygwin”:http://www.cygwin.com/ are the way to go with git on Windows. msysgit is very straightforward to install, but Cygwin gives you all the other Unix tools should you decide to go further down the Unix/Linux rabbit hole.
mcritz
I’m the only designer in my office that uses Git. It’s too technical for the average artsy-fartsy type to “get” git. I wish there was “Mindless Git”. For instance, “Dropbox”:dropbox.com does versioning on its synced folders. I know every save gets versioned away in the ionosphere, mindlessly. Mac needs that built-in. Time Machine isn’t frequent — or powerful — enough.
John Faulds
Good article, Al. I’ve been reading about Git for ages and been meaning to get around to trying it and after reading this article (or should I say while), I finally have. Now I’ve just got to start using it. ;)
Relocation to Atlanta
You’re right, you don’t have to be a code writer to need a tool like this. As a web developer, I’m often creating dated filenames, dated directories, pre, post, active, you name it…just to try and keep up with everything that’s archive, current, and future.
I may give this a rey.
Lucas Sandery
I don’t think that’s really getting started. Maybe you like the command line a lot but, for most tasks, Git GUI is sufficient and is far more illustrative of what Git actually does, especially for those new to VCSs.
I love Git and use msysgit every day. I don’t have to use the command line very much to be productive.
I like my favourite bash commands set as (often global) tools in the in the Tools menu. I have stash git stash save, unstash git stash pop, great for quickly stopping what you’re doing to do something else then, going back to it without any branching. For regular exporting, I use some variation of git archive—format=zip -9 master > ../latest_version.zip, that one archives adjacent to the repository directory.
Dormilich
Mac users that already use “MacPorts”:http://macports.org/ (e.g. if you’re running their Apache/MySQL/PHP/Python ports) will find Git and some applications around Git (e.g. GitX) there as well.
xipmix
Thanks so much for this article, I finally clicked on the ‘staging area’ and so much more of git makes sense now.
The key thing was your explanation of how to turn a somewhat tangled set of changes into a sequence of well-organised commits.
The “double-add” discussion with Marcel underlines this nicely – to a new user it would be easier to understand if the initial add was called something like “git-include” (ie include this file in the repository) that auto-committed the change. Then the need for a “git-add” later, if changes were made to the file, would seem natural.
This is the first time I’ve seen (in a lot of reading about git) such a vivid example of what the staging area is good for. I encourage you to try to get this example into the git reference documentation; it’s one every user of a text editor can relate to.
benknight
I would imagine what they were thinking with the hot pink was to remind people you can style the selection, being a starter’s kit and all. Regardless it’s still a good example.