Version Control


We leverage Github, the leading version control provider, to manage code and facilitate code reviews.

Simplified Git Flow

We use a simplified version of Git-Flow when working with Git.

  1. Create a new feature branch from the develop branch.
  2. Implement changes to the feature branch and commit periodically.
  3. Open a pull request from your branch with your proposed changes to kick off a PR review.
  4. Discuss and review changes with reviewer making changes as needed on your branch. Your pull request will update automatically.
  5. Squash and Merge pull request with develop branch. Delete the feature branch.
  6. Merge develop to master then tag and release from the master branch.

Branch Overview

Branches are important when working with a team to isolate and manage all the different activities that may be in progress at any given time.

Anything in the master branch is always deployable.
The develop branch is a long-lived branch and serves as a staging area for work in progress. Code is merged from develop to master when releasing new versions to production.
A feature branch is created off of the develop branch. It represents a collection of changes for a new feature, bug fix or experiment. These are short-lived branches that will be removed after completing the unit of work.

Create Feature Branch

When beginning work on a new feature, bug fix or refactoring, start by creating a new branch off the develop branch.

Do not create your own fork of the project repository. This does not meet our security needs and can result in private repositories being made public. Create branches off of the organization owned repository only.

Changes made on a feature branch don’t affect the master or develop branch, allowing work to be done in isolation, safe in the knowledge that the branch won’t be merged until it’s ready to be reviewed.

It’s important that your new branch is created off of develop when working on a feature or a fix. Your branch name should be prefixed with the issue/user story number and include a short, descriptive name (e.g., 1234-reorderlist-items). For experiental branches like a larger refactoring use a short, descriptive name without a prefix (e.g., swift4).

Implement Changes

Once your branch has been created, it’s time to start making changes.

Work in small increments and commit at logical points throughout the day. Each commit has an associated commit message, which is a description explaining why a particular change was made.

For larger changes, it can be helpful to merge from the develop branch periodically to stay up to date with changes and avoid big merge conflicts.

Open Pull Request

Once work is complete on a new feature, push changes from the local branch to the remote and create a new Pull Request in Github to initiate review with collaborators. Use a descriptive name for the PR and include notes the reviewer if necessary.

See Pull Request Prerequisites for guidance on steps to take prior to submitting a Pull Request.

Discuss and Review

Once a Pull Request has been opened, a team member start a code review. The reviewer can make comments and start discussions in line.

Continue to make commits and push to the branch with any changes in response to the reviewer feedback.

See Pull Request Review Guidelines for guidance on performing a code review.

Squash and Merge

Once a Pull Request has been approved, it can be squashed and merged into the develop branch. Now that your changes have been verified in production, it is time to merge your code into the master branch.

Clean up the old feature branch both on the remote and the local workspace.

Tag and Release

Once the develop branch is considered complete and passes all tests, it can merged with master. Create a new tag on master for the version number and release create a new release.

Atomic Robot is an independent app agency

Ready to start your next mobile project?