I’ve returned from (arguably) the last Magento Imagine and have almost recovered from my personal branch of the flu that seems to have been burning through the attendees. While hacking and spluttering and read Reilly Chase’s post on using git as a solo developer and thought it was a great idea for an article.
I think I started using git about 10 years ago (geez) and at the time was acting as solo dev on most of the projects I worked on. It seemed slightly useful, but honestly seemed like a lot of overhead for not much benefit. I already had my own system of local backups that I was quite comfortable with.
But, git was “how real developers worked” so I started to use it. I set up a remote server to use as my remote repo (didn’t use github at first) and had relatively few problems using it locally – but I was paranoid about running it on the live server. It seemed like one flubbed command could really mess up the site!
So, at the time I installed the repo outside of the web root on the live server, and manually copied changed files from there to where they needed to go. Obviously not the most efficient way to do things!
Eventually I moved on to managing a pretty large open source project on github, and quickly began to learn the value of git in the multi-developer context. And once I became a developer working with about a dozen other devs on projects that used an entirely git-based workflow, it was clear how critical a tool git is for multi-developer projects.
But, what about the single dev?
Beyond the obvious advantages of using git (branching/merging/etc) there’s a few others I’d like to highlight
- Detecting changes on the live server – if site is running from the repo on the server, a single git status command will show you changed files or new untracked files. Very handy in cases where an attacker has gained access to the server!
- Remembering what you did last – there may be big gaps of time between when I work on a client’s site – while waiting on feedback/payment/etc. A quick git log shows the recent commits. Or look at github/bitbucket to see what you were up to. This is also a great way to reconstruct work done on a site for billing purposes, if you forgot to log your hours :\
My strategy
I generally keep my workflow pretty simple. Almost all work is done locally in MAMP (I mostly work on LAMP stack sites), tracked within a single master branch. I use Bitbucket for my remote. I do occasionally create a branch if I’m messing around on something I think I may need to keep around longer term – best example was working on converting an older site to use PHP7.2 – while ongoing work was going on in PHP 5.6.
On some more complex projects, I have a staging server set up to allow the client to see changes before they go live. This is usually a cheap Lightsail instance. I set up the repo containing the site files there, and just do a quick git fetch when I want to see what updates will be applied, and git pull to bring them down.
The live server is set up the same way. I always do a fetch first to make sure I know exactly what’s going to be pulled on to the live site. No surprises!
I realize I could use hooks or something to have the live server automatically update when I push commits to master, but with my setup that doesn’t make much sense – I prefer to do this manually. And as I mentioned, running git status on the live server now and then gives me one more level of security check… I do have one project moving towards an architecture of multiple front end nodes, in which case I will have to change this model. In that case, I don’t want to have to login to each node to pull down the latest commits. A bridge to cross when I get to it!