Best Practices for Working with Github in Team Settings
I originally started writing this post as internal documentation for our own team here at Petabridge, but I thought this would be useful for our readers and users as well.
Github has evolved over the years into a vast, rich ecosystem filled with lots of first and third party features that make developers more productive and effective.
Yet the vast majority of developers haven’t had much experience working effectively with Github in day-to-day work. Many developers don’t have a Github account; some have created some simple projects or filed some bug reports on popular projects; and few have forked a repository and made a pull request.
In this post you’re going to learn the best practices for working with teams of developers on Github who are working towards producing production-ready software. Everything in this post is equally applicable for developers working behind the firewall on proprietary software via Github Enterprise as it is for developers who want to submit a patch to popular open source projects like Akka.NET.
Two Unnecessary Costs of Software Development
Putting my “Chief Technology Officer” hat on for a second, there are lots of cost levers behind the total expense of software development and most of them are necessities. Yes, we should always allow plenty of time and money for testing and user feedback. Yes, we should try to pay down technical debt. We’re not talking about any of that.
What I’m talking about are unnecessary costs, waste costs, that can be avoided via using Github effectively as a communication platform among a development team. Those costs are:
- False starts - designing the wrong thing from the beginning;
- Blind alleys - designing the right thing using the wrong strategy.
In both of these cases the developers’ time and company’s money is wasted....