There are many options when working with Source Control. In ISE 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 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
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).
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:
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).
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
- Git
--local-branching-on-the-cheap - Azure DevOps
- ISE Git detailsdetails on how to use Git as part of a ISE project.
- GitHub - Removing sensitive data from a repository
- How Git Works Pluralsight course
- Mastering Git Pluralsight course