about processes and engines

talked about git and github

last night at the August Ninjava meeting.

The second talk was about Erlang, Joe Norton gave us an overview on this language and tools around it. Extremely interesting. Looking forward to dig more about the finite state machines lib available.

Here are my slides, very shallow. Follow the links after the slides to learn more.

(pdf download)

* to reach the Tech Talk from Linus Thorvalds about Git
* Scott Chacon’s “git internals” peepcode, excellent
* Scott Chacon’s talks about git, I recommend the ‘voice over‘ he did with his RailsConf 2008 slides
* Oliver Steele’s git workflow (very nice graphs) (followup on commit policies)
* Ryan Tomayko’s git workflow (maybe it’s better to read it after Oliver’s one)
* the user manual
* (the source itself)

Written by John Mettraux

August 21, 2008 at 11:41 pm

Posted in git, github, ninjava

5 Responses

Subscribe to comments with RSS.

  1. Thanks for mentioning PeepCode! The link you provided was actually to our screencast. Scott’s PDF is here:

    Geoffrey Grosenbach

    August 22, 2008 at 6:13 pm

  2. Oh, updated the link.

    Thanks a lot. Keep up the great work !

    John Mettraux

    August 23, 2008 at 1:25 am

  3. Interesting. One thing that has always bothered me in the distributed version control is the lack of one true revision number. I guess that can be countered by methodology, but so far I haven’t seen any best practices documents (admittedly I haven’t searched much.)

    If you have time, it would be great if you can write a piece about how did Git changed your work style (i.e. things you couldn’t do before, but can now; things that are now so much faster that you can do them more often; things that you stopped doing; commit granularity, etc.)

    Dimitar Dimitrov

    August 25, 2008 at 6:26 am

  4. Hi Dimitar,

    I recommend the two blog posts :

    As for myself, “I don’t branch enough”, Git makes branching easy so I should use it more, but I currently don’t [branch enough].

    For the “one true revision number”, would something like this commit number : tend towards your ‘ideal’ ?

    Granted “” is a bit long, but Git is smart enough to let you use just 4 or 5 of the first chars of this md5.

    For the post on the impact on my work style, I need more time.



    John Mettraux

    August 25, 2008 at 6:51 am

  5. Thanks, both articles were great! If nothing else, one thing I realized is how much I am dependent on my IDE :-)

    Usually I hold a commit until I have a working feature, so sometimes I find myself wanting to go back in time a couple of hours – in this cases I use IDEA’s Local History (sort of persistent undo). Consequentially, I often have Ryan’s problem separating unrelated changesets, in which case I use the IDEA changesets manager and sometimes the “shelve changes” function (if I want to test each commit separately.)

    Git allows to handle these scenarios from the command line without limiting the editor and other tools you use. Another cool feature is the ability to separate changesets after the fact.


    Dimitar Dimitrov

    August 26, 2008 at 1:14 am

Comments are closed.

%d bloggers like this: