Blog Tags: 

Git tip: how to merge multiple projects into one big repository

A while back I decided it would be a good idea to combine a loose collection of related Git repositories into one big Git repository.

The rational for this was that I noticed that often the same logical change had to be broken up into multiple commits across these previously separate repositories in a way that made it difficult to track which changes were part of the same change. In other words it artificially fragmented the commits and made revisions harder to track.

Blog Tags: 

Use the stash, Luke (git-stash)

I was in the middle of developing a new feature for the TurnKey Hub when I received a bug report that needed to be fixed.

What to do? Throw away my current changes? Checkout a clean branch? Of course not! Just stash my changes away, fix the bug, and get my changes back so I can continue development.

Blog Tags: 

Git - Fixing commit mistakes

I use Git. I use it a lot. I basically use it for everything I do, from code revision control to revisioning my notes, my journal, even my email archive (don't ask, it's a long story).
 
As with anything you do, you are bound to make mistakes.

Using git and rsync to synchronize changes on a staging box to a live server

The problem: working on a live web site is a bad idea

Anyone who's ever worked on a sufficiently complex web site knows it's a bad idea to work directly on the live server hosting the site for a couple of important reasons:

  1. It's disruptive to visitors: If - sorry when you break something - your visitors are going to be exposed to it. Nothing creates a bad impression faster than a broken web site.
  2. Fear is stressful, stress kills productivity: you know if you mess around too much with the web site there's a good chance you'll break it. Naturally you don't want this to happen so your mind becomes preoccupied with the fear of making mistakes, and its hard to focus on what needs to be done.

We develop this web site and test all non-trivial changes in a local TurnKey Drupal instance running inside a virtual machine. This means we can experiment and screw things up with no consequences. I find removing that source of stress makes you much happier and more productive as a web developer.

Working like this raises a few practical questions though:

  • How do you push changes from the development box used for staging to the live web site without accidentally overwriting changes made by someone else?
  • How do you track who changed what?
  • When you screw things up on your development box, how do you reset the changes you've made and start again?