Shared Repository Model and Version Control Anti-Patterns

Shared Repository Model

The Shared Repository Model is prevalent with small teams and organizations collaborating on private projects. Everyone is granted push access to a single shared repository and topic branches are used to isolate changes.

Pull requests are used to initiate code review and general discussion about a set of changes before being merged into a mainline "master" branch.

Decide whether to use Feature Branches

If you have very few developers and you are using git as more of a source repository than a fully featured version control system, then consider committing files and merging directly to master;  Otherwise, you should probably be using feature branches.

Use Reasonable Workflow and Project Tracking Tool

When you use feature branches you should follow a reasonable workflow such as github workflow.

• Store User Stories/Requirements in Project Tracking Tool (Jira / Pivotal Tracker / RTC)
• Track feature stories by tasks that are assigned a ticket/tracking number
• Reference ticket number in feature branch name
• Developer creates feature branch, commits file changes and then submits a Pull Request
• Other developers are notified of Pull Request, perform code review and the last one merges the feature branch to master ***

*** The last developer to perform the code review may need to perform work to merge feature branch code with master -- which can happen with other developer(s) have changed code pertaining to the feature branch between the time the feature branch was created and when the feature branch is submitted for code review via the Pull Request.

Merge

Reasons to Merge

• When developers create feature branches
• Multiple developers are working on same branch and you want to see each persons contributions separately
• Clearly delineate feature branch work from merge work
• Slightly easier to do when developers merge directly to master

Rebase

Reasons to Rebase

• When developers merge directly to master
• Keeps git history clean when not using feature branches (avoids "merge bubbles")

Team Development Workflow Anti Patterns

• There are multiple developers and you are not using feature branches
• Management is emailing spreadsheets around to track progress
• There is no project management software in place
• The PM software is not integrated with the version control software (github)
• There is inconsistency with usage of PM or version control software among team members