Working with Git
By default all work should be stored on github, with repositories using the ds-
prefix. If your project uses any secrets such as api keys, using git-crypt
, keybase
, and trufflehog
is recommended.
Branches
Treat the master branch as a place for finished code and always work on another branch. This makes code review easy even for the initial version of a project, as you can submit a pull request to merge the first working version of the code into master.
How often should I branch?
Follow the Git Flow convention. Each major feature should be developed on a branch. This should be reviewed (see Code Review) by at least one other team member and passed any unit/integration tests before the code is merged into the master branch. Working in this way also encourages the development of modular code.
When considering what constitutes a major feature think of the reviewer. Aim to strike a balance between having long pull requests that require a lot of time to review and short but frequent pull requests. As a ball park figure, accurate review of 200-400 lines of code should take 60-90 minutes to review with an accuracy of 70-90%.
README.md
All projects should have a README.md
that gives enough information for someone to understand the project and get started with the code. If a project has multiple components, consider nesting and linking them, with each readme explaining a specific component.
├── README.md (General overview)
├── Component 1
│ ├── README.md (Specific instructions)
│ ├── code.sh
├── Component 2
│ ├── README.md
│ ├── code.sh
...
.gitignore
Maintain a good .gitignore
file. This should exclude anything other than code or data that is cleared to be hosted on GitHub. https://www.gitignore.io offers a generator produces common .gitignore patterns for particular programming languages (this can be installed as a terminal function)
▶ gi python
### Python
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
# C extensions
*.so
...
Configuration
One common mistake with Git is not correctly associating your local account with the remote one. To do this, make sure your globally configured email is the same as one of your GitHub emails.
▶ git config --global user.email "me@email.com"
Similarly, if you want to, you can sign your commits with your gpg
key (see Secrets).