Great to see someone taking on a different perspective on GIT and highlight some of the reasons why and how should (not) be learning GIT.
Though I consider becoming familiar with basic commands is quite essential, we often forget how important it is to understand and teach what GIT is actually doing.
Personally, I found the learning curve to be quite steep, but as with many other tools, the rewards in workflow and productivity definitely make it worth the effort.

Git was written by kernel developers for kernel development

[Citation needed]

Yes, it was written by developers who were also developing the Linux Kernel, so a key need was that Git could handle large projects. But it was not built “for kernel development”.

Git is not something that we have co-opted or shoe-horned into web development. It was developed from the beginning to work with a variety of software projects. I feel that attempting to link it in this way to a big “scary” project like Linux kernel development makes Git appear more complicated than it actually is and leads to thinking like Chris Gaskell’s;

Developers are naturally wary of GIT

You don’t speak for all developers…what exactly is there to be wary of? There is a reason most tutorials focus on the “the five most popular Git commands”, this should be all a developer needs to begin using Git in a basic form. The number of otherwise exceptionally smart developers I’ve spoken to who have avoided Git because they think it is too difficult or complicated is absurd.

We need to stop building Git up to be some Goliath sized beast. It IS a tool, and a really rather simple one at that.

Hey, I tried to make a more generic git cheatsheet that I think will help some people who don’t want to create their own.

Unlike a lot of cheatsheets, this one is organised by what you’re trying to achieve when you use each command, rather than by the name of the command.

Hope it helps someone, you can download it here: http://startuptechnology.wordpress.com/downloads/

Wow. This is meta in all the best ways. :)

It does seem to me, though, that there’s a bit of a bootstrapping issue here: in order to be able to design a workflow, one must already have some idea of Git’s capabilities and conceptual model. Or is this process intended to prompt people to notice where their own model is still vague and go consult others for help?

I’ve been using git exclusively for nearly five full years now – I began with CVS 14 years ago, moved my self/team to SVN soon after, and hated them. Git really gives me the flexibility I need when developing, and combined with github.com or something similar, is the perfect setup. The review/permission layer inherent with pull requests is a big help and I wish companies were more open to adopting that method.

I used cvs for a few years, then svn for at least 4 years. I read more and more articles about Git (and many open source projects are now available via Git) and but it’s yours that will make me take the plunge : I put the migration in todo list of my resolutions for 2014!

I use git professionally, and I’m here to tell you the two great secrets to using git:

1) Get a visualizer. Gitx for Mac or gitg for Linux are best. Keep it open while you’re working on anything that’s not trivial, and it will help you keep track of where you are. The difference is enormous.

2) Make temporary branches any time you’re doing something potentially dangerous.

About to do a merge, or a rebase? Or anything that makes you the slightest bit worried that you’re about to screw things up? Do this:

This creates a “placeholder” branch named “foo” that represents the exact current state of your workspace at this moment.

Now, no matter how badly you screw the pooch from this point forward, you can always do

And you’re right back where you started.

I have been a developer for almost 30 yrs. I have used CVS, Clearcase (back when Apollo owned it), Subversion and many other SCS/SCM solutions. I do understand the concepts.

I mentor a FIRST team and have been trying to explain GIT to the kids. Arg. The tutorials I have gone through have been written by people who already understand Git and SCM in general. They don’t “bridge” to the unitiated well and the kids are busy with homework and cannot devote a lot of time to trying to learn the philosophy of the tool.

Your article is very clear and well written. I am going to ask the kids to read it. I bet I get a lot of “now I understand it”‘s. Thanks for putting your thoughts to paper!

Thanks for the gitflow diagram. I’ll be sharing that the next time we talk about our deployment/release management strategy.

Great article, thanks for taking the time. Developers are naturally wary of GIT but after a couple of weeks things start to click. It’s then the power of the worksflows become apparent.

Thanks again

Very nicely written. This way of thinking could be applied to most technology. Instead of trying to adapt ourselves to everything we come across try to adapt it to us and we’ll get the best out of it.

This is an interesting approach to the problem of learning Git. I’ve been using it for a while now at my job but I’m still somewhat confused by it now and then. I think more tutorials should take this “for grownups” approach.

A wonderful crack at making these concepts become personal, and thus easier to understand for us grown-ups.