Jun 17, 2026

Beginner's guide to Bitbucket branches, pull requests and Sourcetree

Learn why branches matter, how pull requests protect your main codebase, and how to use Sourcetree with Bitbucket to review and merge changes confidently.

Why this workflow exists

If you are new to Git, branching can feel like extra admin. You already have the files on your machine, Bitbucket has the repository, and Sourcetree gives you buttons for commit, pull and push. Why not just make the change and push it straight to main?

The short answer: because shared repositories need a safe place for work in progress.

A branch gives you that safe place. A pull request gives other people a clear way to check the work before it becomes part of the main project. Sourcetree makes the day-to-day Git actions visible, so you can learn the workflow without memorising every command on day one.

The basic mental model

Think of your Bitbucket repository as the shared source of truth for a project.

main is the stable version of the project. Some teams call it master, develop, or trunk, but the idea is the same: it should be safe for everyone to build from.
A branch is a separate line of work. You can change files, commit often and push updates without disturbing main.
A pull request is a request to merge one branch into another. It shows what changed, why it changed and what reviewers think about it.
A reviewer is another person who checks the change before it is merged. They are not there to catch you out; they are there to protect the project and help improve the work.
A merge is the moment your branch becomes part of the target branch, usually main.

Branches and pull requests are not just Git ceremonies. They create a pause between “I changed something” and “everyone now depends on it”.

Why beginners should use branches

1. Branches reduce risk

When you work directly on main, every push changes the shared version of the project. If something is half finished, broken, or missing a file, everyone else can be affected immediately.

A branch keeps your changes isolated until they are ready. You can commit a rough first attempt, tidy it later, and only ask for review when the branch tells a complete story.

2. Branches make work easier to understand

A good branch usually has one purpose:

Fix the login validation bug.
Add the new contact form.
Update the homepage copy.
Refactor the navigation component.

That focus helps reviewers understand the change. It also helps you. If the work goes wrong, you know where the experiment happened and can switch back to main without dragging the failed attempt with you.

3. Branches support collaboration

Two people can work on different branches at the same time. One person might improve the footer while another fixes a payment bug. Their work can be reviewed and merged separately instead of becoming one large, risky bundle.

4. Branches create a useful history

When each branch has a clear name and each pull request has a clear description, the repository history becomes easier to read later. Instead of asking “why did this line change?”, you can find the pull request and see the original context.

Why pull requests matter

A pull request, often shortened to PR, is where the team decides whether a branch is ready to merge.

A good pull request answers three questions:

What changed? For example, “Added validation to the enquiry form.”
Why did it change? For example, “Users were submitting empty email addresses.”
How was it checked? For example, “Tested the form in Chrome and confirmed the error message appears.”

Pull requests are valuable because they:

Catch mistakes earlier. A reviewer might spot a missing file, unclear naming, accidental deletion, or edge case.
Share knowledge. Reviewers learn what changed, and the author learns from feedback.
Improve consistency. Teams can discuss patterns before code is merged.
Create accountability. The approval trail shows who reviewed and when the branch was merged.
Reduce last-minute surprises. Smaller reviewed changes are easier to release than large unreviewed batches.

The goal is not to slow people down. The goal is to avoid avoidable problems reaching the shared codebase.

A simple Sourcetree and Bitbucket workflow

Here is a beginner-friendly flow you can follow for most tasks.

Step 1: Start from the latest main

Open Sourcetree and select your repository.

Click Fetch to ask Bitbucket what has changed remotely.
Checkout main by double clicking it in the branch list.
Click Pull to bring the latest main changes onto your machine.

This matters because you want your new branch to start from the most recent stable code, not from an old copy.

Step 2: Create a branch

In Sourcetree:

Click Branch.
Give the branch a short, meaningful name.
Create the branch from main.

Useful branch names include:

feature/contact-form
bugfix/login-validation
content/update-about-page
chore/upgrade-dependencies

Try to avoid names like johns-work, changes, or MyStuff. They do not help anyone understand the purpose of the branch.

Step 3: Make your changes locally

Edit the project files in your editor. Keep the branch focused on one task where possible.

If you notice an unrelated issue, make a note of it and create a separate branch later. This keeps the current pull request easier to review.

Step 4: Review your changes in Sourcetree

Go back to Sourcetree and look at the File Status view.

Before committing, ask yourself:

Are these the files I expected to change?
Did I accidentally change generated files, local settings, or temporary files?
Can I explain why each change is needed?

Sourcetree lets you inspect the diff before committing. This is one of the best habits you can build as a beginner.

Step 5: Commit small, sensible chunks

Select the files you want to include, write a clear commit message and click Commit.

Good commit messages are specific:

Add required email validation to contact form
Update homepage hero copy
Fix broken mobile navigation toggle

Less helpful messages include:

changes
fix
work in progress

You do not need a commit for every tiny edit, but you should avoid one huge commit that mixes several unrelated changes.

Step 6: Push the branch to Bitbucket

Once you have at least one commit, click Push in Sourcetree.

Make sure your branch is selected. Sourcetree will publish it to Bitbucket so other people can see it.

At this point, your work exists in two places:

Locally on your machine.
Remotely in Bitbucket on your branch.

It is still separate from main.

Step 7: Create a pull request in Bitbucket

Open the repository in Bitbucket. You will often see a prompt to create a pull request from your recently pushed branch.

When creating the pull request:

Set the source branch to your branch.
Set the destination branch to main.
Write a short summary of the change.
Add any testing notes or screenshots if relevant.
Choose one or more reviewers.
Create the pull request.

A simple pull request description might look like this:

Code
## Summary
- Added email validation to the contact form
- Updated the error message copy

## Checks
- Tested empty email submission
- Tested valid email submission
- Confirmed the form still works on mobile width

Step 8: Respond to review feedback

Review comments are normal. They do not mean you failed.

A reviewer might ask for a naming change, a missing check, a clearer message, or a smaller adjustment. Make the requested change on the same branch, commit it and push again from Sourcetree. Bitbucket will update the pull request automatically.

This is one of the main benefits of pull requests: the discussion and the changes stay together.

Step 9: Merge the pull request

Once the pull request is approved and any required checks have passed, it can be merged into main.

Depending on your team, either the author merges it or a reviewer does. After the merge, your branch's changes are part of the shared project.

Finally, return to Sourcetree and:

Checkout main.
Pull the latest changes.
Delete the old local branch if you no longer need it.

This keeps your local workspace tidy and ready for the next task.

What pull request reviewers should look for

If you are asked to review someone else's pull request, start with the purpose of the change rather than jumping straight into individual lines.

Useful review questions include:

Does the change solve the problem described?
Is the pull request small enough to understand?
Are there accidental or unrelated file changes?
Is the naming clear?
Has the author explained how they checked the work?
Could this change break an existing flow?
Is there anything another team member would find confusing later?

Good review comments are specific and respectful. For example:

Could we rename this variable to customerEmail so it is clearer in the validation block?

That is more useful than:

Bad name.

Pull reviews work best when everyone treats them as a shared quality step, not a personal judgement.

Common beginner worries

“What if my branch gets out of date?”

That happens often. Someone else may merge changes into main while you are still working. In Sourcetree, fetch and pull the latest main, then bring those changes into your branch using your team's preferred approach, usually merge or rebase.

If you are unsure, ask before clicking through conflict dialogs. Git conflicts are easier to fix slowly than to untangle after guessing.

“What if I make a mistake on my branch?”

That is exactly why the branch exists. If the mistake has not been pushed, you can adjust it locally. If it has been pushed, you can make another commit to fix it. The pull request will show the updated result.

“What if the reviewer asks for lots of changes?”

Treat the feedback as part of the work. Sometimes the first version opens up useful discussion. The important thing is that the discussion happens before the change reaches main.

“Isn't this overkill for small changes?”

For very small teams or low-risk content edits, it may feel heavy at first. But the habit is still useful. A short branch and a short pull request can take only a few minutes, and they leave a clear record of what changed and why.

Practical habits that make the workflow easier

Pull main before creating a branch. Start from the latest shared code.
Keep branches focused. One branch should usually mean one task.
Commit deliberately. Review the diff before each commit.
Push regularly. Bitbucket cannot back up or review work that only exists on your machine.
Write helpful pull request descriptions. Explain the change, not just the ticket number.
Review kindly and clearly. Aim to improve the work, not win an argument.
Delete merged branches. Old branches create clutter and confusion.

Conclusion

Branches and pull requests give teams a safer way to change shared code. Branches let you work without disrupting main. Pull requests let others review, discuss and approve the change before it is merged. Sourcetree helps beginners see each step visually: create a branch, commit, push, open a pull request, respond to feedback and merge.

Once the workflow becomes familiar, it stops feeling like extra process. It becomes a safety net: one that protects the project, improves collaboration and helps beginners build confidence with Git.