Jeudi du Libre: “How to use Git to look good”

4:56 pm freesoftware

I will be giving a short training session on Thursday December 1st 2011 at 19h30 in the Maison pour Tous, la Salles de Rancy, on the subject “Présentation et initiation à l’utilisation de Git pour la gestion d’un projet communautaire (ou comment donner l’impression qu’on est un super codeur ?)”(roughly translated: “A presentation of Git usage in community software projects (or: how to make people think you’re a super coder)”. The basic idea is to show people how to use git to (a) save their work regularly and (b) reorganise patches using

git rebase --interactive

to make themselves look smarter than they are.

For those interested but unable to attend, I will be borrowing heavily from Federico Mena Quintero’s 2008 blog post Why I want to have the children of git rebase –interactive

This is a short session, but I plan to plough through a lot of content, like this:

  • 10 minutes: What is version control, how does Git (and other DVCS) differ from svn
  • 20 minutes: Git basics (initialising a repository, allowing others to pull from it, how clone, status, add, commit, update, pull, push, branch works)
  • 20 minutes: Branching, merging – good policy for maintaining a common trunk, submitting patches for review with git format-patch and send-email
  • 20 minutes: git rebase, with –interactive using pick, edit and squash; A word of warning on squashing or editing commits when others are cloning your code
  • 20 minutes: Questions

Are there things I absolutely should talk about which aren’t listed? I’m assuming that most of the attendees will be somewhat familiar with some version control and potentially even git already, and don’t need a full one hour on the virtues of version control, so I’m assuming I can fly through the basics pretty quickly.

 

6 Responses

  1. Alexandre Franke Says:

    git bisect is definitely on the list of cool commands you want to show.

  2. Phil Says:

    If you’ve talked about git before, then this probably will be obvious, but:

    Having previously tried to present git in about 15 minutes, I’d like to offer the advice of trying to break down what you are trying to explain very carefully in advance. Even a very good understanding of git doesn’t necessarily help to explain it, because so many concepts layer on top of each other – the interesting things can get lost by having too many references to earlier ideas that people might not have a clear enough picture of.

    Also, I have some slides (in English) that I think helped me get across some basics, and the argument that git is actually a much better fit for software dev than svn. Email me if that’s of any interest.

  3. Dave Neary Says:

    @Phil: Thanks for the advice – in general I try to prepare well before giving any presentation, and this one will be no exception. I’ve previously given training on Linux developer tools, including Git, and I’ve done multi-day training courses on svn a few years ago.

    What do you think are “the interesting things”? I’m thinking that a basic explanation of the mental model for Git is important, explaining the differences between remote, local and staging, and the basic idea of branches, rebasing and merging is necessary (eg. “Why do I have to git add a file that Git already knows about when I change it?”); more explaining version control and centralised vs distributed version control, rather than explaining anything specific to Git.

    The things I do not intend to talk about at all are:

    Integration with IDEs
    Deploying a Git server/publishing a branch using git: or http:
    Best practices for branching, tagging, setting up permissions, etc
    About 50% of Git commands that do what they say (why explain “git log” or “git status”?)

    Dave.

  4. Phil Says:

    The sort of knots I found myself in were mostly about the number of different variations on concepts. E.g. Local branch (commit history) vs Remote branch (commit history) vs Local branch (label) vs Remote branch (label).

    Logically they all fit into place, but I found it hard to form clear sentences describing things like a local branch tracking a remote branch with a different history. Or how to describe commits with the same changes but different parents. And both of those come up just with rebasing.

    I started by trying to differentiate SVN’s files+versions from Git’s data+versions(+files), which I think helped by letting me then refer to commits in terms of “data” or “changes” rather than “files” (makes explaining the re-adding simpler). I should probably have tried to get more things simplified like that up front, and made sure I could refer back to them.

  5. Dave Airlie Says:

    git add -p
    git checkout -p

    everyone I tell about these is always happy I told them.

  6. Yohann Says:

    Hello,
    thank you for the git training session.
    I heard about git and didn’t wanted to switch from svn to git for silly reasons like “this is the vcs Linus uses !”. You gave me good reasons to switch to git :
    – simplicity of the initial import
    – automatic patch submission
    – offline commits
    – and of course the rebase to make me look smarter!

    By the way, i liked your original post-it présentation, (i just miss they weren’t on a wooden table)
    I hope to see you again.

    Cheers
    Yohann