Source Control
There are many options when working with Source Control. In ISE we use AzureDevOps for private repositories and GitHub for public repositories.
Sections within Source Control
Goal
Following industry best practice to work in geo-distributed teams which encourage contributions from 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:
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
Git
--local-branching-on-the-cheapISE Git detailsdetails on how to use Git as part of a ISE project.
Last updated