Skip to content

Source Control

There are many options when working with Source Control. In ISE we use AzureDevOps for private repositories and GitHub for public repositories.

Goal

  • Following industry best practice to work in geo-distributed teams which encourage contributions from all across ISE 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

General Guidance

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 and Design Reviews).

Creating a New Repository

When creating a new repository, the team should at least do the following

  • Agree on the branch, release and merge strategy
  • Define the merge strategy (linear or non-linear)
  • Lock the default branch and merge using pull requests (PRs)
  • Agree on branch naming (e.g. user/your_alias/feature_name)
  • Establish branch/PR policies
  • For public repositories the default branch should contain the following files:
    • LICENSE
    • README.md
    • contributing.md

Contributing to an Existing Repository

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 CONTRIBUTING.md file).

Mixed DevOps Environments

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

Resources

Last update: December 10, 2024