Introduction

If you want to bring the latest master changes into development, the safest approach is to fetch first and then merge or rebase explicitly. A direct git pull origin master can work, but it hides two operations in one command and makes troubleshooting harder when the branch state is not exactly what you assumed.

Start from the Correct Branch and a Clean Working Tree

Before integrating anything, make sure you are on development and not carrying uncommitted changes that will complicate conflict resolution.

git switch development
git status
git branch --show-current

If the working tree is dirty, commit or stash first.

git stash push -m "pre-master-sync"

That keeps the branch update focused on integrating upstream work instead of mixing it with local edits.

Fetch master Explicitly

Fetch from the remote so you know you are integrating the latest remote branch, not a stale local copy.

git fetch origin

After this, origin/master points to the current remote state without changing your working branch.

Merge origin/master into development

For shared branches, merge is usually the safer default because it preserves history and does not rewrite commits teammates may already have.

git switch development
git merge origin/master

If the merge succeeds, run tests and push the updated branch.

git push origin development

This creates an explicit integration point in history, which many teams prefer for long-lived shared branches.

Rebase Only If Your Team Allows It

If your workflow prefers a linear history and rewriting development is acceptable, you can rebase instead.

git switch development
git rebase origin/master

After a rebase, the branch history changes, so pushing usually requires a lease-protected force push.

git push --force-with-lease origin development

Do not rebase a shared branch unless the team is aligned on that workflow.

What git pull origin master Actually Does

While you are on development, this command fetches master from origin and merges it into the current branch.

git switch development
git pull origin master

That command is valid, but it is less transparent than explicit fetch plus merge. When conflicts or stale assumptions appear, the more explicit two-step flow is easier to reason about.

Resolve Conflicts Methodically

If Git reports conflicts, inspect the status, resolve the files, and then continue the chosen integration operation.

git status
# edit files to resolve conflicts
git add path/to/file

For a merge, finish with:

git commit

For a rebase, continue with:

git rebase --continue

If necessary, abort and return to the pre-integration state.

git merge --abort
# or
git rebase --abort

Keep Branch Synchronization Frequent

Large branch divergence creates bigger conflicts and riskier integrations. Syncing development from master regularly reduces surprise breakage and makes conflict resolution much smaller.

This is a process issue as much as a Git command issue. Cleaner branch hygiene usually matters more than memorizing one special pull syntax.

Common Pitfalls

• Running the update from the wrong branch and merging master somewhere unintended.
• Integrating stale local master instead of fresh origin/master.
• Pulling with uncommitted work and turning a simple sync into a messy conflict set.
• Rebasing a shared branch without team agreement and forcing others to repair history.
• Skipping tests after the merge or rebase and pushing integration breakage downstream.

Summary

• Switch to development and make sure the working tree is clean.
• Fetch first so origin/master reflects the current remote branch.
• Merge origin/master into development for the safest shared-branch workflow.
• Rebase only when your team explicitly wants rewritten linear history.
• Prefer explicit commands over opaque pull shortcuts when branch safety matters.