Using version control
Version control facilitates collaboration amongst a team working on a shared code base. Each change to a code base includes a message explaining the reason for those changes. These messages provide useful context to future developers who may want to understand the reasoning behind different design decisions.
Version control also allows for controlled testing and deployment of known software versions, which is an essential part of any reliable quality control process. Nowadays this will typically be in the form of a continuous integration/continuous deployment pipeline.
Coding in the open
At GDS we use Github to store our git repositories and review work in progress. Source code should be open to the public and published under an open source license.
The GDS Way explains how to manage source code repositories and use GitHub securely.
What you should be able to do
- Understand and follow your team’s branching and code review process
- Understand the benefits of having a clear commit history
- Write clear commit messages for your changes
- Be able to clone a git repository
- Be able to create a branch
- Be able to make commits with clear commit messages
- Be able to push changes
- Open a pull request
- Understand what rebasing is
- Understand when it is necessary to force push (and when NOT to :-))
- Understand the git styleguide
We’d expect a Junior developer to be able to do all of these things.
- Rewrite commit history before submitting a pull request in order to make it clear
- Understanding the trade-offs of long running feature branches
- Knowing when to split things into multiple pull requests
- Being skilled at structuring commits into a coherent narrative
- Understand git hooks and when to use them
Writing clear commit messages helps other developers (including your future self) understand why changes were made.
See styleguide: git for some good examples.