I have had a lot questions on how we have been working lately. After doing an article for Uses This: Silicon Prairie Edition, I thought it was time to update everyone on a few changes on our development process. While using GitHub.com for development isn’t anything new, seems like how we use is (even if as I have found out along the way is the way GitHub.com themselves use GitHub.com).
Git
Previously this year, I declared our love for Mercurial. I grew up and realized that git allows us to work exactly the way we need. Without starting a developer holy war, here are the reasons that sold me:
- Great integration with Xcode (iOS / Mac SDK).
- Its installed and ready to go on a Mac; when you install Xcode and the developers tools.
- Branching is simple: the branch names don’t matter and go away when deleted.
- Rebasing is fantastic when you are trying a bunch of different methods and don’t want all your crumby commits to be merged back up the tree.
- More people we work together with, use Git.
So those are the reasons that took me away from Mercurial. Now it’s time to mess around with GitHub.com more.
Problem: working with a team, building features, fixing bugs, adding code, removing code and working at different hours and locations.
Solution: GitHub.com
Like many many other companies and open source projects, we use Github.com as our central communication zone for code and code related activities. For every active project we have a private repository setup within our organization. I emphasize active, because there are a lot repositories we have that aren’t being worked on right now. There is no need to host those on Github.com. Anything non-active goes to a few local places for backup purposes.
Besides using Github.com to browse and manage our codebase, we use it for their pull requests feature. A pull requests is most commonly used in open source projects to merge in code you worked in a forked repository. Well turns out, you can use pull requests within a non-forked repository against other branches.
A little background: we will create a branch from master for a feature set (say: awesome-neat-new-feature-a). We’ll write, remove, edit a bunch of code in the branch. Keep in mind, the master branch is sacred. Its supposed to (always) build successfully. We are supposed to always have a stable working version of code from there. Sometimes I need to demo the app, I rely on Master to be there. If the feature hasn’t made it into Master, then its not ready to demo. No one ever commits in master (only tag or branch from); unless dire circumstances warrant… and you will be judged on that dire circumstance.
Conversations: We use the pull request as a conversation about the branch a developer is working on. These requests will group commits together and it allows you comment along the way. The conversation can go on and one, using code to reference issues, screenshots, etc. Or just be a set of commits and be done with it.
Timing: We create pull requests at any time from a branch to be merged backed into master. Its important to know that this can be done at anytime. It can be done right away, and put in the comments… ” hey I’m working on this branch for the next couple days, just a heads up.” or done at the end. “hey dudes, this feature is all donezo.”.
Code review: Now we have code reviews within that conversation. For example I can see a commit and comment on that commit or individual line. Great example: I have been working with new people and we have been working remotely and needing to understand well what we are doing. Once we agree that the pull request (the feature is done, etc) is complete, I (in this case the so called fearless-lead) will merge it back in. Once the request is merged back in to master, we have a nice trunk graph of code with all the commits including what we put in the pull request in our git repository. Anytime you can go back to the pull request and read the conversation too, if you need. Its quite nice.
Ugh. The only kink in this model is for super trivial fixes. Agreeing to always do a new branch and a pull request is too much. Right now we are all or nothing; so pull request happens no matter what. This will likely change in the future.
.. After doing things this way, I found out that Github.com does the same thing.
Other stuff. Besides hosting our code, we use github.com for all the other technical management of the project. All major active projects are private github.com projects managed by our organization account. We use the wikis to document things from coding styles, to API details, to simple what the app is supposed to do. We use github issues also for all our tasks, bugs, features, etc. Everything is one place and it all just works.
Thats it.
There you have it, how we have been developing lately.
Related posts:
