Simple daily git workflow

by Andy Croll

Filed under Work Style

I’ve been looking for an everyday guide to git for a simpleton. The git simpleton in question is me.

One of the key things that Arun has brought  to my programming is the rigor of working in a multi-developer environment, an area in which my experience is weak. I’ve worked in larger groups as a designer, but it’s possible to sit outside the flow of development lifecycle and drop HTML templates into the process.

However even I understand the importance of version control, and the emergence of git as the source control of choice (and the all marvelous github) mean I have been using git but only in a cack-handed way. What I was missing was the regular day-to-day repeatable how. If you’re familiar with source control, this is not going to be big news, but I want to capture this as I’m still learning as its only really this week I feel I ‘get it’. So here it is, I’ve even created a cheatsheet, which you can download at the end of the article.

There’s load of ways to install git (standard setup article is under construction) so whether you want to install from source or download an installer, knock yourself out.

Simple Daily Git Workflow

Once you’ve set up your repository on Github (go ahead a buy a nice plan while you’re there) this is process we’re following for every line of code we right:

Before you do anything make sure you’re up to date with all the changes made on the remote master branch by other developers.

git checkout master
git pull

We like to make a branch for every issue/bug/feature we’re trying to build so we start a new branch for each, this gives us the ability to always have deployable code in the master branch. We can also abandon branches where we’ve gone wrong and always head back to master, like insurance!

git checkout -b your-branch-name-here

This creates a new branch for you to start making you changes and switches you into it.

Do your work here!

The key thing to remember at this stage is to commit often, *really often* the smaller your commits the more you can undo any damage or later go back and see what you did. Whether its a change of layout of a single template or a single test passing commit it separately.

git status

This shows you the files that have changed.

git add .

This adds any new files you have created. You can add a series of specific individual files if you like, simply replace the dot e.g. ‘git add your/filename/here‘

git diff

This shows the differences line by line. You could use GitX if you’re on a Mac to deliver a lovelier graphical representation ‘git diff | gitx‘.

git commit -m "detailed message here"

Commits your changes with a nice little informative message as to the changes you’ve made. At this stage if you feature/bug/issue isn’t completed simply loop back up and do another small chunk of work!

Once your feature is complete or your bug is squashed it’s time to bring the master branch up to date.

git checkout master
git merge your-branch-name-here

For your next feature or bug just create another new branch. For us we’re linking all our branches to github issues, as Arun mentioned. So our branch names are all called issue-n to match up with that.

When you want to resynchronise with github.

git push

Job done.

For those of you who’ve made it this far you might be keen to download a pretty cheatsheet I’ve put together. I have pinned it behind my own monitor, lest I forget.

View Comments to “Simple daily git workflow”

  1. Winston

    Arun taught me this as well:

    > git diff | mate

    so that all the diff stuff is piped into TextMate, which is awesomely useful for me.

    And you can simply do “git -am”, instead of “git -a -m”.
    Saves 2 char (and time) for a slow typist like me. =)

    Nice job with the PDF!

  5. Phil Welch

    “git commit -a -m “detailed message here”"

    No–you don't need to use -a after you've already used “git add .”, because the -a flag just repeats the “git add .”. And if you were only trying to commit specific files, the -a flag will override it. This actually interferes with how Git is meant to work–you can edit ten files but split that up into multiple commits with judicious use of “git add” (let's say you fixed a bug in one file and added a feature in the other files and want to commit them separately).

  9. Andy Croll

    Good point, but I was mainly looking to the simplest way of keeping the master clean. I understand there are benefits to rebasing, but for us, for now, this seems to work best.

    In fact in the last link you've posted it's a very much 'you can use merge if you like' kinda vibe.

  14. Jason Ong

    if you do “git fetch” first, you have ability to do things like these:

    1. Check file changes. Useful if you wanna do migration only when necessary.

    git whatchanged ..origin/master

    2. Check new commits in remote master before merge

    git log ..origin/master

    3. Thoroughly check differences between remote & local master

    git log -u ..origin/master

  18. exhuma

    About committing you write:

    > git commit -m “detailed message here”

    Which is technically incomplete. It's either …

    > git commit -m “detailed message here” <filename>

    … to commit only one file. Or …

    > git commit -a -m “detailed message here”

    … to commit all modified files.

    Another important consideration when writing commit messages is to keep the first line short. The git docs recommend keeping it shorter than 50 chars. The primary reason for this is that some git commands use this as summary. For example “git log –oneline” or “git format-patch <revspec>”. In the latter case, the first line will be used as the e-mail header and the filename. Keeping it short helps to keep things tidy and readable.

    I find “git format-patch” extremely useful when working on projects where you have no write access. In this case short summary lines come in handy. Imagine you find a project which has a public git repo and you want to contribute some code. The easiest way to do so is this:

    > git clone <repo>
    > … edit … test … commit …
    > git format-patch -o patches origin

    then send patches as e-mail to upstream developer (yes, you could also use “git send-email”…)

  19. Andy Croll

    Interesting point about keeping the commit message short.

    However, as pointed out by Phil Welch above, in my (as simplified as possible) git process I'm already doing 'git add .' meaning I can leave out the '-a' from the 'git commit'.

  20. mwilden

    If you do use short commit messages, you probably also want to include a more detailed explanation below. To do this, I use

    git commit -v

    which pulls up my editor with a diff of the changes I'm about to commit. Then I can type a short commit message at the top, followed by a blank line, followed by the longer message.

    Another nice tool is

    git add -p

    which shows you each change and prompts you whether to add it. Helpful for breaking up changes into multiple commits.

    There's more, but you are a simpleton, after all.

    :)

  21. Fabio Kuhn

    AFAIK there is a difference between git add . and git commit -a
    git add . takes all the modified and new files to the HEAD. But ignores not the deleted files.
    git commit -a takes the modified and deleted files. Ignores the new files.