Using Git Collaboratively: My Tutorial At PHPNW12
I haven't really talked much about my upcoming tutorial session at #phpnw12 next month before now, but I hope there's still time to convince you to come along and learn how to use Git as your team grows in size.
That's what I'm teaching: a strategy, plus supporting tools for Git called HubFlow, that will help you stay sane - and more importantly help you keep delivering - as your team starts to collaborate on your product.
It isn't my strategy: the credit must go to Vincent Driessen, who first blogged about GitFlow at the start of 2010. And they aren't my tools: again, they originally come from Vincent. All I've done is adapt them for working against GitHub - hence the name aoHubFlowa; but if BitBucket is more to your taste (or wallet) then rest assured that both tools and strategy work can be adapted for there too.
Maybe you don't need this strategy. If you're working on one-off consulting gigs for clients, where you can get in quick and get out quick, then HubFlow might not be necessary. But if you're working on any sort of product or service, either commercially or open-source, then I can strongly recommend HubFlow to you - even if you're just at the one-man startup stage. And the benefits of adopting HubFlow only increase as your team grows in size.
I've already put a lot of effort into documenting HubFlow, and if you've previously read the docs, you might be feeling confident enough to adopt it by yourself. If you do, I think that's awesome, and you should go for it without delay. Please do email me if I can help in any way. I'm passionate about everyone adopting the fundamentals of software engineering, and few things are more fundamental than good source control.
But if you're still reading at this point, I hope that I can convince you to buy one of the remaining tickets for my tutorial session at #phpnw12. I don't personally profit by it - all of us teaching at #phpnw12 are volunteers - but maybe you will.
What I'm teaching is the approach that I've introduced to DataSift. You might not have heard of us yet; we provide a platform for filtering social data in real time, handling terabytes of data a day at full firehose-scale, and many thousands of incoming data every second. And every piece of that data goes through code written in PHP.
Although we're a young startup, we've already grown beyond 20 developers, and with that many people collaborating to build that platform, with every team working at their own pace, we needed to adopt a common way of working together with Git and GitHub so that the company continued to scale well.
- It had to be a way that allowed every developer to take full advantage of Git, especially when it comes to committing their work early and often.
- It had to allow developers to form ad-hoc teams that worked at their own pace.
- Remote working is a fact of life these days, and it had to work just as well whether everyone is in the office or working from somewhere else.
- It also had to ensure that only work that had been finished made its way into any of our releases.
- We wanted to make sure that there was an opportunity to review every change before it went into a release. Code reviews play an important part in delivering high-quality work time after time after time.
- We didn't want pending releases to hold up new development, ever.
- And if something did screw up in production, we needed a way to go back to our last known good version, fix it, and release *that* - all without disrupting any pending releases or existing ad-hoc teams.
- Finally, it had to be easy to teach to people who are new to Git and GitHub, preferably by wrapping complicated Git operations up inside a single command each time.
Those are the benefits that HubFlow gives us. And at #phpnw12, I'll be teaching everyone who attends my tutorial session how to get those benefits too.
What makes me qualified to teach this topic? And what makes me qualified to be teaching at all?
I've got 18 years of experience setting up and
Truncated by Planet PHP, read more at the original (another 1949 bytes)