There are many different options when working with Source Control. In CSE we use AzureDevOps for private repositories and GitHub for public repositories.
- 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
Consistency is important, so agree to the approach as a team before starting to code. Treat this as a design decision, so include a design proposal and review, in the same way as you would document all design decisions (see Working Agreements).
The team should at least be doing the following:
- agree on their branch, release and merge strategy
- define approach to commit history (linear or non-linear)
- lock the default branch and merge using PRs
- agree branch naming (e.g.
user/your_alias/feature_name) - for public repositories:
- default branch contains the LICENSE, README.md and CONTRIBUTING.md file
TODO: Add more content and details here!
- Link work items
- How often to commit
- When to push
- Git
--local-branching-on-the-cheap - AzureDevOps
- The GitHub Hello World
- CSE Git details details on how to use Git as part of a CSE project.
- GitHub - Removing sensitive data from a repository