Skip to main content

IV Use of Version Control

In our organization, we use Git as the sole version control system for managing and tracking changes in our software development projects. Our entire codebase is hosted on GitHub, a cloud-based platform for Git repositories, which allows us to efficiently manage our projects, track issues, and collaborate effectively.

The usage of Git enables developers to work concurrently on different features using branching, to record a detailed history of all changes through commits, and to combine changes efficiently using merges. This not only enhances traceability and accountability but also facilitates effective collaboration among developers.

A. Code Check-In Policy​

Our code check-in policy emphasizes the importance of maintaining a clean, functional, and well-organized codebase. Before code can be checked into the master branch, it must meet the following criteria:

  1. No //todo or Commented Out Code: Code should not contain //todo comments or sections of commented-out code. All //todo items should be addressed and any commented-out code removed before check-in.

  2. Applied Code Format: Code should adhere to the organization's established code formatting and style guidelines. Consistency in formatting improves code readability and maintainability.

  3. Removal of Unused Code: Any code that is not being used should be removed from the codebase. Unnecessary code can clutter the codebase and potentially introduce confusion and errors.

  4. Coverage by Tests: Important parts of the code, such as classes, functions, and modules, should be covered by tests. More details about our testing strategy will be provided in the relevant section.

Adhering to these rules ensures that the code in the master branch is of high quality, is easy to understand, and functions as expected. It also facilitates effective collaboration and minimizes the risk of introducing bugs or issues.

B. Branching Strategy​

Our organization adopts the GitHub branching model which emphasizes simplicity and efficiency. We typically focus on fixing bugs in the latest version and maintain that all code merged to the main branch should be potentially releasable.

When developing new features or bugfixes, we create separate branches for each task. Branch names follow a specific convention: <type>/<team>/<name-of-branch>.

  • type: Indicates the purpose of the changes made in this branch. It could be "dev" for new additions or "fix" for bug fixes. For instances when a feature makes sense only in combination with other features, an "integration" type can be used.

  • team: This could be the name of the team or the individual developer working on the branch.

  • name-of-branch: This should reflect the feature or bugfix being developed. Words in branch names are separated by dashes (-).

Integration branches should be regularly rebased onto the main branch to stay up-to-date with the latest changes. Smaller features added to this branch should be squashed to keep the history clean and to avoid unnecessary intermediate commits. All merges to the integration branch should be code reviewed to avoid having to review huge amounts of code. This branching strategy helps to streamline our development process and fosters efficient collaboration among developers.

C. Pull Requests and Conflict Resolution​

Pull requests play a vital role in the collaborative development process. A pull request is created when a developer wants to merge their feature or fix branch back into the main branch.

To maintain the integrity and consistency of the main branch, pull requests must be free of conflicts before they can be reviewed and integrated. Prior to initiating a pull request, developers are required to merge or rebase the latest changes from the master branch into their feature or fix branch.

The description of a pull request should contain a clear and concise explanation of the changes introduced, such as "Implemented feature XYZ" or "Fixed bug ABC". In case of substantial changes, like architectural modifications or the addition or removal of dependencies, a thorough rationale must be provided.

This allows reviewers to understand the context of the changes, facilitating a more effective review process and ensuring that all changes are purposeful and beneficial to the overall project.

D. Automatic Builds​

All dev/* branches are automatically checked by the CI build. This ensures that the code compiles and that all tests pass. The build must be fixed before merging the branch into the main branch.

All changes to the main branch are built automatically. If the Build is successful, services will be deployed to the staging environment automatically. If the project has a NuGet build, the NuGet package will be published to nuget.org. The version of those NuGet packages is 0.0.YYMM.DDxxx and differs from the version of official releases, where we use tagging and semantic versioning.

E. Release and Tagging Strategy​

We create releases by tagging the main branch with a specific version. This version is then used as the version for services as well as for NuGet packages. We tag with the following scheme: rMajor.Minor.Build e.g r1.0.0.