Choosing a Branching Strategy in Sourcetree: Git Flow vs. Manual Branching

The Release Management Dilemma

\n

When managing a team project in Sourcetree, the primary challenge is ensuring that unstable feature code never reaches the production branch while maintaining a clear history of releases. The decision is usually between using the built-in Git Flow automation or managing Standard (Manual) Branching. The wrong choice leads to either rigid constraints that slow down development or a “wild west” repository where merge targets are inconsistent.

\n\n

Comparing Sourcetree Workflow Options

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Feature	Git Flow Integration	Standard Branching
Branch Creation	Automated (Feature/Release/Hotfix)	Manual naming and selection
Merge Targets	Predefined (e.g., Feature → Develop)	User-defined per merge
Versioning	Automated tagging on release finish	Manual tag creation
Flexibility	Low (Strict naming conventions)	High (Any naming/structure)

\n\n

Trade‑offs and Constraints

\n\n

Git Flow Integration

\n

Sourcetree's Git Flow is a GUI wrapper around the AVM (Adaptive Versioning Model). It simplifies the transition from develop to master by automating the merge and tagging process. However, it relies heavily on naming conventions. If a user manually renames a branch or deletes the develop branch, the integrated buttons may fail to locate the correct targets, forcing a manual reset of the Git Flow configuration.

\n\n

Standard Branching

\n

Manual branching requires the engineer to explicitly select the source and destination for every merge. While this avoids the rigidity of Git Flow, it increases the risk of human error merges—such as accidentally merging a feature branch directly into master (production) instead of develop (staging).

\n\n

Implementing a Git Flow Release Cycle

\n

To implement a structured release using Sourcetree's automation, follow these steps. This assumes you are using Sourcetree version 3.0 or later on Windows or macOS.

\n\n

\n
1. Initialize Git Flow: Click the Git Flow button in the toolbar. If the repo is new, Sourcetree will prompt you to name your production branch (usually master or main) and your development branch (usually develop).
\n
2. Start a Feature: Select Feature → Start New Feature. Enter a descriptive name (e.g., user-auth-fix). Sourcetree automatically branches from develop.
\n
3. Finish a Feature: Once the task is complete, select Feature → Finish. Sourcetree will merge the feature back into develop and delete the local feature branch.
\n
4. Initiate a Release: Select Release → Start New Release. This creates a release branch from develop for final polishing and bug fixes.
\n
5. Finalize Release: Select Release → Finish. Sourcetree performs three automated actions: it merges the release branch into master, merges it back into develop, and creates a version tag (e.g., v1.0.1) on the master branch.
\n

\n\n

Validation and Risk Mitigation

\n

Because GUI merges can occasionally obscure complex merge conflicts, always validate the result using the visual graph. Before finalizing a release, check that the master branch pointer has moved forward and that the tag is correctly anchored to the latest commit.

\n\n

Verification Check: Run the following command in the Sourcetree terminal (or any Git CLI) to ensure the tag was created correctly:

\n\n

git tag -l

\n\n

Expected Result: The list should include the version tag you specified during the Finish Release step.

\n\n

Rollback Procedure

\n

If a Git Flow release is finished but contains a critical bug, you must revert the master branch state. Since the operation changed the state of two branches and created a tag, perform the following:

\n\n

\n
1. Right‑click the commit immediately preceding the release on the master branch.
\n
2. Select Reset current branch to this commit.
\n
3. Choose Hard (Warning: This will discard all uncommitted changes).
\n
4. Manually delete the incorrect version tag via the Tags sidebar.
\n