Both in my professional life and in my personal life as an open source project lead, I spend a lot of time working with git in general, and GitHub in particular. GitHub publishes a command line tool called hub, which is a more convenient way than the website for doing a few specific tasks and in particular I've been using it more and more for opening pull requests. Continue reading
Last week I wrote an email to a client who hasn't yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You're not using source control? Read This! (PDF, no registration needed).
The document goes on to talk about the available tools (git, Hg, SVN) and give a sales pitch for _why_ source control has benefits for an organisation. There are also some action points to follow to implement source control if you haven't already taken the leap, which I hope will help anyone looking to take that step - it's kind of awkward in this day and age to admit that your organisation doesn't have source control, but however this situation arose, hopefully this document wraps up my thoughts on how to find a good way out! Continue reading
Last week I had the pleasure of speaking at Confident Coding in San Francisco. This was a one-day event for mostly front-end developers, covering the things everyone seems to know but which seem like silly questions to ask - and it has an all-female speaker lineup.
Today I thought I'd share my "cheat sheet" for git - the commands that I use on a day-to-day basis. I've used entirely the command line tools, since those are the same on every platform. GUI tools and IDE plugins are available for git so it is worth taking a look at what is available for the development environment you use.
In git, you don't checkout code, you clone a repository. You end up with a local repository on your filesystem, which behaves as both the repo and as your working copy. In git, you always clone the whole repo, not a subdirectory, and the metadata is all stored at the top level, in a directory called
When you are ready to clone the repo, create the directory to store it in and change into it. Then type:
git clone [url]
Here's an example, showing a clone of my private joind.in repo on github. Continue reading
This article originally appeared in the May 2012 php|architect magazine.
Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.
The tl;dr Version for the Impatient
- Fork the main repo so you have your own github repo for the project
- Clone your repo onto your development machine
- Create a branch
- Make changes, commit them
- Push your new branch to your github repository
- Open a pull request
This article goes through this process in more detail, so you will be able to work with git and github projects as you please.
This post is mostly about a tutorial I will be delivering at PHPNW on October 5th in Manchester, UK, and why I think a tutorial that contains no PHP belongs at a PHP conference
In October, I'll be delivering a tutorial at the mighty PHPNW Conference which contains very little PHP. Why? Because I think, as developers, it's our other professional skills that suffer. As a consultant, I work with lots of different teams, and it is very rare for code to be the problem (and the one time it was, it wasn't the only problem!).
In web development, our biggest challenges are not writing code, we can do that. But getting the code safely from one place to another, with many people's work preserved, having our platform(s) correctly configured and understanding how to use them, making use of the tools in the ecosystem which will help us improve the quality of our code; these are the big challenges we face, and that's why I proposed this workshop and why I think all these topics are important. Continue reading
One project I'm working on at the moment involves finding my way around changes in a codebase that isn't mine - and it's quite large. I was doing pretty well with a combination of
git log and
git show and in particular two of my favourite existing tricks:
Just a quick tip because I'm working on a different git workflow at the moment with one of my clients, and it struck me that this usage pattern is something I don't usually write or speak about at all. Most git setups have one "main" repository, and either:
- there is a gatekeeper that manages merging to here
- all developers have write access
In this case, I'm working with the second option, so I'm pushing to the upstream repo. I'm also pushing to a live repository as well, so I thought I'd outline the commands I'm using. The setup here is the main github repo, and I have my own fork of that, which is cloned onto my laptop. I can push to both that main repo, which I'll call "upstream" (because the github documentation does and it makes sense!) and another repo that I'll call "live". All in all it looks something like this:
Someone emailed me recently, having read my book and wanting some advice. Here's a snippet of his email:
So here's my problem.
We dont know deployment. We work from same copy on one test server through ftp and then upload live on FTP.
We have some small projects and some big collaborative projects.
We host all these projects on our local shared computer which we call test server.
All guys take code from it and return it there. We show our work to clients on that machine and then upload that work to live ftp.
Do you think this is a good scenario or do we make this machine a dev server and introduce a staging server for some projects as well?
I wrote him a reply with some suggestions (and my consulting rate) attached, and we had a little email exchange about some improvements that could fit in with the existing setup, both of the hardware and of the team skills. Then I started to think ... he probably isn't the only person who is wondering if there's a better way. So here's my advice, now with pictures! Continue reading