Source Control

August 16, 2018 ยท View on GitHub

There are many different options when working with Source Control. In CSE we use VSTS for private repositories and GitHub for public repositories.

Goals

  • Following industry best practice to work in geo-distributed teams which encourage contributions from all across CSE as well as the broader OSS community
  • Improve code quality by enforcing reviews before merging into master branches
  • Improve traceability of features and fixes through a clean commit history

Evidence and Measures

  • The master branches are locked and merges are done through PRs which follow the guidelines outlined in the Code Reviews section
  • The commit history is consistent and the commit messages provide useful information about the WHAT and WHY (instead of the HOW) of the change.
  • All public repositories follow the OSS guidelines highlighted below
  • No secrets are published or part of the public commit history

General Guidance

Consistency is crucial, therefore the team has to agree on their approach before they start to code. At a minimum, the team should do the following:

  • agree on their branch, release and merge strategy
  • define their approach to commit history (linear or non-linear)
  • lock the default branch and merge using PRs
  • agree on how to name branches (e.g. user/your_alias/feature_name)
  • for public repositories:

Resources

Q&A

Q: I just committed a secret - how can I remove it from the git history?

A: use git reset to remove them from the commit history. If you already pushed your changes to a public branch, ensure that all contributors that pulled these changes will pull the now updated branch.

If you have published these changes to a public repo like GitHub, you will first need to change the secrets. Then follow the instructions to remove sensitive data from a repository. This can be accomplished through the git filter-branch command or using the BFG Repo-Cleaner and both options are covered in the instructions.