Git hard or go home

I am in love with Git. It’s the neatness junkie’s dream come true. Multiple people can code away safely, independently, then every commit can be written and rewritten at any time to end up with a tidy, coherent product. As long as you know what you’re doing, that is.

With the years I worked out a few strategies for taming Git, making both mine and my collaborators’ work easier. Perhaps these’ll save you some headaches down the road.

Understand the model

A prerequisite to understand most of Git’s concepts is learning how the data model works. It’s so important, that before I let developers do anything with Git, I force them to read through the “Git Basics” chapter of Pro Git. The rest they can learn as they go. In essence:

  • all commits are nodes in a directed graphs, where
    • when multiple commits point to the same parent, they’re all branches,
    • when one commit has multiple parents, it’s a merge,
  • there’s no such thing as “branch” or “tag” in itself, they’re just labels given to specific commits—friendlier names to refer to than 63949df, so:
    • deleting a branch or tag merely deletes the label. The commit 63949df is still there and you can reference it. At least until Git decides to do garbage collection, when all orphaned commits are permanently deleted.
    • a “fast forward” merge moves a label to a different commit, as long as the branch you’re merging into didn’t have any commits of its own. Since there’s no separate merge commit for it, there will be no trace of this merge later in the graph, so make sure that’s what you want. Otherwise do git merge --no-ff.

Take your time to study the model, the charts and perhaps the commit graph in some existing repository. Working with branches will suddenly make much more sense for you, and more importantly you’ll grasp the concept of rebasing much, much quicker.

Rebase freely

Rebasing is the wonder broom that keeps the commit graph tidy. It’s what you do to get rid of commits saying Merge branch 'master' of https://github.com/your-name/your-repo.git which make the commit graph look like a Guitar Hero script—completely unreadable.

You can:

  • amend broken commits, if you:
    • mistyped the last commit’s message do git commit --amend and edit the commit,
    • forgot to stage some changes, add a file, do
      git add <missing changes>
      git commit --amend -C HEAD
      
  • squash obsolete commits, once you realize a commit other than your last one could use amending, do:
    git add <missing changes>
    git commit --fixup=<hash of commit to amend>
    git rebase -i --autosquash <hash of commit to amend>^
    

    Note the trailing caret ^ in the last line.

  • rebase instead of merge on pull, pretty please. This makes sure master (or any other branch) is a single, straight line, that’s easy to follow. This will also cause fewer conflicts and make the remaining ones easier to resolve. Use either git fetch && git rebase origin/<your branch> or git pull --rebase.

There’s a caveat to rebasing—it changes history, discarding some commits and replacing them with other ones. That’s not an issue, as long as all of the commits you’re replacing are only local to your sandbox, but once you pushed these commits out into the world, you might be peeing into the pool.

Branch smartly

Just because branching and merging with Git is easier than with older version control systems, that doesn’t make branching any less dangerous:

Start juggling too many [branches] at once, and you’re bound to drop a few. In most source control systems, you can create hundreds of branches with no performance issues whatsoever; it’s the mental overhead of keeping track of all those branches that you really need to worry about. Your developer’s brains can’t exactly be upgraded the same way your source control server can (…)

To stay on top of your repository:

  • keep branches short and small, branch off, make your changes, create a pull request and merge as soon as possible. I used to advocate the gitflow model in the past, but nowadays I consider its long-lived develop and release branches an anti-pattern, and favor the simpler GitHub Flow. Fewer branches mean fewer (ideally just one) sources of truth.
  • delete remote branches, once merged, usually right after a pull request is closed. If you ever need to resurrect a branch and add something to it, you can always push it anew. Otherwise it’s hard to see which branches are still active.
  • don’t git cherry-pick or commit the same patch of changes to multiple branches. It’s confusing and will likely give you headaches during merging. If you stick to a single, long-lived master branch with short-lived feature branches, you shouldn’t ever need cherry-picking. Otherwise, use rebasing to move a commit from one branch to another.

Push thoughtfully

Once your changes are out there, on the remote(s), you might as well assume everybody else has already fetched them. GUI clients like SourceTree have auto-fetching enabled by default. If you now realize you’d still like to do some amendments—say fix a silly typo or rebase the master branch—you’re screwed. You’ll have to ask everybody to git reset their local branches and cause a lot of grief.

Take your time before you push anything, and never, ever mark the “Push changes immediately to remote” checkbox in your Git client. It’s like disabling the Undo feature. Commit your changes locally, leave them baking for an hour or a day, then review them—see if there are no missing or obsolete line changes, files, whether commit messages are correct—and only then run git push.


Reduced amount and magnitude of merge conflicts, actually useful commit graphs, immediately obvious location of the most current code—all benefits I drew from applying these here practices. Call it Git etiquette or call it a way to improve the ratio of pleasure to pain in using Git. And do share your own tips in the comments, please.

Michał’s conference war chest

It’s not unusual for conferences to cost an arm and a leg. At €1,000 or more for just the entry, on top of which come travel and accommodation, and I often attend two or three events a year. That’s a pile of money in need of justification spending, and I can only do so if I bring back lots of valuable information. Here’s what I do nowadays—the tools and tricks I worked out for surviving and thriving as a conference attendee.

Preparation

During a conference I want to focus strictly on acquiring information and connecting with other attendees, so to free up time I prepare a lot upfront.

Session selection comes first. Conference schedules usually appear piece by piece, so a week or two before the event I go through all sessions and plan my agenda. The last thing I want is to make haphazard, effectively random decisions at the venue.

  • If I’m attending with any colleagues, we sit down together to split up the sessions and cover more ground.
  • If there’s more than one interesting session in a given time slot, I write down all of them and prioritize. This way I have more options when my first choice turns out to be a flop or suddenly gets canceled.

I add selected sessions into Google Calendar, synchronized across all of my devices. Some conferences have dedicated apps to store one’s schedule, but these may or may not work to my liking or could have issues on shaky Wi-Fi. Plus I quickly would’ve acquired a pile of useless apps and accounts.

GOTO Berlin schedule in Calendar

I’m really big on notes. Before the conference I setup a fresh Google Doc, since I’ll be taking notes on a tablet, with pre-entered:

  • sections for each chosen session, ordered chronologically,
  • names and
  • Twitter handles of speakers.

GOTO Berlin conference notes

Using Google Docs has a number of advantages:

  • I can share the document with colleagues, both at the venue or back at the office, where they can follow me in real-time,
  • Google Docs’ context-aware spellchecker is pretty decent, which helps a lot when (mis)typing on a tablet,
  • the chronological order lets me get ready quickly by opening the document and scrolling down to the next empty section,
  • speakers’ Twitter handles make live tweeting easier.

I’ll often write the Twitter handles with the conference hashtags, ie.:

 @mpaluchowski #craftconf

Note the leading space. This snippet I can easily copy and paste after every quote I tweet during a session.

D-Day(s)

The conference days are always intense, both physically as well as mentally, so my focus here is to stay light and fit.

I carry my own shoulder bag, currently the excellent Camel Active Dakar, which contains my tablet, wallet, business cards and a pen or two.

Camel Active Dakar shoulder bag

Conferences usually hand out their own bags, but most of these aren’t convenient to carry around for a full day. I carefully selected a good bag, that:

  • keeps my hands free all day—especially beneficial at standing lunches,
  • doesn’t bite into my shoulder(s),
  • doesn’t bump around my hip thanks to its vertical orientation,
  • easily fits into my lap during a session, when space is tight,
  • carries everything I need—the Camel one can easily carry a 12″ laptop or A4-sized documents.

Michal taking notes at CraftConf 2015

My device for note taking is currently the iPad Air 2. A laptop wouldn’t do because the vast majority won’t last a full day on batteries and I sure as hell don’t want to waste time on recharging.

Typing on a tablet is pretty cumbersome, but gets better with practice, plus Google Docs’ spellchecker helps a lot, and anyway I won’t be publishing raw notes anywhere without post-processing. A colleague is happy doing notes on an iPad Mini so the smaller form factor could work as well.

iOS 9’s Peek function was a real blessing, since I tweet a lot during sessions, on top of taking notes. Earlier I had to keep switching between the Google Docs and Twitter apps, whereas now I can just slide in Twitter on the side for a quick tweet and return to notes. Thanks, Apple!

A conference day is really hard for the body since I spend a lot of time sitting still in sessions, while my brain keeps working in high gear, burning lots of fuel and not getting nearly enough oxygen to clean up the trash from metabolism. This means unless I pay attention to my body, by the end of day I’ll likely develop a headache and won’t see much from the conference party. So I:

  • drink a lot of water, either carry my own bottle and keep sipping during sessions, or drink a glass at each break. The side effect is having to visit the bathroom often, but there’s a trick to that too.
  • move a lot in between sessions—no sitting, lots of walking, gesticulation, even leaving the venue when possible.
  • eat light, opting for complex fuel sources, like protein or complex carbohydrates. No pastry or sweets of any kind—these would burn up quickly leaving me hungry and distracted.

Finally, I try to sit near convenient exit rows, so that I can easily leave the session if I don’t like it, or reach the toilet before the crowd does. Trust me, this is a real problem during male-dominated software events.

Post-processing

There’s little value in all the information I acquire at a conference if it stays inside my head. Sharing it with others and turning it into action is where the payoff starts.

Conferences are often followed by a weekend, which is super convenient since I can focus on something completely different and then go back to my notes with a fresh look on Monday morning.

It takes me a day or so to process notes, where I rearrange them to:

  • group into common themes, ie. microservices, DDD, Agile etc.,
  • reorder into something that makes sense in the context, rather than whatever the speaker(s) thought would,
  • list out tools, books, blog posts and other resources I saw mentioned,
  • later add links to talk recordings, once they were posted.

Finally, I produce a brief summary from the pile of information, adding my own judgment of where I see the industry right now, or how it changed compared with previous conferences. This usually turns into a blog post, richly decorated with photos and tweets from the event.

We take a look at all materials with my colleagues to decide what is most relevant to us and what we’d like to try out now or later. These go into our regular planning and I get back to everyday work, counting down to the next great conference.

I love my iron

I do. It glides easily over my clothes, leaving finely straightened surfaces. It has a big water tank and is very efficient, with one load usually being enough for a whole load of clothes. It simply makes ironing easy, almost… fun.

The tools we use for daily mundane tasks are crucial. Unless they’re top-of-the-line in terms of performance and usability, we’ll hate them and do anything to avoid using them. We won’t use the bug tracker if it takes ten actions to report a simple issue. We won’t use the project management suite if it doesn’t provide our current tasks at a glance. And we sure won’t branch our code if the operation takes 15 minutes to complete. The money that went into licensing those tools will effectively be wasted, together with lost productivity and energy wasted on complaining.

If you’re in charge of buying anything for your corporation’s use, let the actual users decide on what to buy. And pay whatever it costs, or find something cheaper but identical in function. Do the math and find you’ll gain more in the long run than the couple of bucks you saved upfront.