Source Control
Last updated
Last updated
There are many options when working with Source Control. In we use for private repositories and for public repositories.
Following industry best practice to work in geo-distributed teams which encourage contributions from across as well as the broader OSS community
Improve code quality by enforcing reviews before merging into main 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 and ).
When creating a new repository, the team should at least do the following
Agree on the branch, release, and merge strategy
For public repositories the default branch should contain the following files:
For most engagements having a single hosted DevOps environment (i.e. Azure DevOps) is the preferred path but there are times when a mixed DevOps environment (i.e. Azure DevOps for Agile/Work item tracking & GitHub for Source Control) is needed due to customer requirements. When working in a mixed environment:
Manually tag PR's in work items
Ensure that the scope of work items / tasks align with PR's
Define the merge strategy ()
Lock the default branch and merge using
Agree on (e.g. user/your_alias/feature_name)
Establish
When working on an existing project, git clone the repository and ensure you understand the team's branch, merge and release strategy (e.g. through the projects ).
--local-branching-on-the-cheap
details on how to use Git as part of a project.