---
title: "Branching, Merging and Resolving a Conflict"
description: "Two branches that changed different lines merge on their own; two that changed the same lines cannot, and a person has to decide. A rebase rewrites the history into a straight line instead, which read"
canonical: https://lightmysky.com/learn/computing/branching-merging-and-resolving-a-conflict-mt_l3vFbU7L3E
source: https://lightmysky.com/learn/computing/branching-merging-and-resolving-a-conflict-mt_l3vFbU7L3E.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Branching, Merging and Resolving a Conflict

Two branches that changed different lines merge on their own; two that changed the same lines cannot, and a person has to decide. A rebase rewrites the history into a straight line instead, which reads better and throws away what actually happened.

Subject: Computing · Area: Software Engineering · Ages 18 to 19
Page: https://lightmysky.com/learn/computing/branching-merging-and-resolving-a-conflict-mt_l3vFbU7L3E

## Ready when they can

- Merge two branches and identify the common ancestor the merge used
- Resolve a conflict by choosing what the combined code should mean, not by picking a side
- Say when a rebase is a better choice than a merge, and when it is a worse one

## Lesson: Merging work without losing meaning

A merge joins two branches at their shared base, the ancestor both grew from. Lines touched on one side only slide in on their own. Lines touched on both sides in different ways stop the tool: it cannot know which meaning you want.

**Example.** You renamed a setting on main while a teammate rewrote its checks on feature. Keep both intents: the new name with the new checks, then run the tests. Deleting one side blindly throws real work away.

A rebase instead replays your commits onto the tip of the other branch, drawing one straight line. It reads cleanly, but it rewrites history: dates and parents change and the true branching is gone.

**Tip.** Rebase a private branch before sharing to keep review simple. Merge a shared branch so the true history stays. Never rebase commits others already built on.

**Recap.** Merge from the shared base, resolve by meaning, and rebase only what nobody else uses.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Version Control as a Graph of Commits](https://lightmysky.com/learn/computing/version-control-as-a-graph-of-commits-mt_oKsDRKirMy)

## Opens up

- [Code Review: Reading a Change You Did Not Write](https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s)
- [Continuous Integration and the Build Pipeline](https://lightmysky.com/learn/computing/continuous-integration-and-the-build-pipeline-mt_z__G4nfjwh)