Version Control Branch Workflow

You've been a lone developer, cloning your repository, making changes locally and pushing them back up to your remote. What happens when other developers need to make changes at the same time you do - and in the same repository? How do you ensure the changes follow your coding standards and are of sufficient quality? This is where implementing a version control workflow is crucial, to ensure changes are reviewed and merged back into the main code line.

A common version control (git) workflow for a team has the following steps:

• Create a branch for the changes you are going to make. A branch is an isolated version of the code that you can work on offline without impacting other developers on your team. A branch would typically be for a new feature or a defect fix.

• Commit changes to your branch locally. You can keep track of your commit history locally while you work.

• Push your changes to the remote repository

• Create a Pull request so that one or more people on your team can review your changes.

• Review the pull request. One or more team members perform a quality check on the code. The criteria for checks of these changes will often be laid out in a code review checklist, which is likely to include the coding standards of your team or organization.

• Complete the pull request. The team members who are required to review your changes agree that the criteria for changes have been met. The pull request is completed and the changes are merged into the main code line, i.e., the master branch.

• Delete the branch. Once the code changes and history are merged, it's good housekeeping to delete the branch.

This workflow is often called the Feature Branch Workflow or Topic Branch Workflow