Source control is still about managing change in content over time. Though key benefits of modern source control are being missed if your process is not improved. We’ll explore these additional benefits:
First, what is modern source control? Is there a git replacement out there? There likely is something newer gaining popularity somewhere, but we are talking about git here. A technology like git that originated in 2005 doesn’t sound modern, but it’s flexibilty allows for reinvention in evolving workflows and usages. Plus, vendors of products for remote repositories extend those capabilities.
Git is not prescriptive. A person can work with a local repository however they want. The product of that workflow can be synced with the remote repository. It is not until other people enter the picture that any agreements must be made. What each person does on their local copy of the repository is their business. Conformity to agreements must only exist on branches pushed to the remote repository. How often changes are staged or committed is a personal preference locally. Whether rewrites happen in many branches or the same branch is the author’s prerogrative as it doesn’t exist from anyone else’s viewpoint unless pushed to the remote repository.
Actually, the vendors with products to manage remote repositories provide this capability. Their products provide features that protect certain branches, enforce rules on others, and let the repository administrator configure these choices. Teams can work a variety of ways, but a few workflows have gained widespread popularity. Just search for “flow” and “git” together.
While local repositories allow for personal choice, remote repositories facilitate combining that effort into something greater. Individuals can contribute to the same effort, the same file, or even the same line in a file. Conflicts must be resolved when combining multiple efforts into one work, so there must be a system to review changes and conflicts as a group.
These “pull request” are actually another feature provided by the vendors of products for remote repositories. The look and feel varies but the process is generally the same. An author of a change submits a request to incorporate their change on one branch to another. Collaborators are assigned to review their request and the contents of the changes. The reviewers provide feedback or approval to the author. A conversation take place as comments in the context of the document being discussed to form agreement. Rounds of changes can occur on the same pull request before consensus between an author and reviewers is reached.
Approval or rejection of a pull request is communicated to the author in the status left by each reviewer. Once the necessary combination of reviewers approve, the author is free to combine their work into the remote repository. Approvals can be reset if changes occur after approval. Also, changes to the destination branch can require approvals to reset if not already merged. The pull request and approvals become part of the remote repository’s history and serve as accountability. The approval process is a configurable feature by the vendors of products for remote repositories. The options vary but typically allow for different approval standards by branch.
In addition to being a system of record for change and approvals, remote repostories are enablers for action. Events on remote branches can act as a trigger for action in the context of the introduced change. Examples may include an automated build or release process. Again, these are features provided by the vendor of products for remote repositories.