Skip to content

Commit aeee9ef

Browse files
committed
Update info + add diagram
1 parent a55e1f9 commit aeee9ef

File tree

2 files changed

+15
-3
lines changed

2 files changed

+15
-3
lines changed

docs/testing-deployment-publishing/branching-collaboration/branching.md

Lines changed: 15 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -522,13 +522,25 @@ YAML files play a key role in managing and resolving conflicts during the merge
522522
Why didn’t all my changes appear after merging two branches?
523523
</summary>
524524
<p>
525-
In merging, Git copies only the differences (diffs) between branches, not the full content from one branch to another. This behavior often leads to confusion, especially if users expect merging to act like a full copy-paste of all data.
525+
Merging in Git is not like copying everything from one branch into another. It’s more like combining changes from two versions of a document based on a common starting point.
526+
527+
Let’s say you and your friend both made changes to the same project:
528+
- You both started with the same original version (this is called the common ancestor).
529+
- You made your changes in `Branch A`.
530+
- Your friend made changes in `Branch B`.
531+
532+
When you merge `Branch B` into `Branch A`, Git compares:
533+
- What changed in `Branch A` since the common starting point.
534+
- What changed in `Branch B` since the common starting point.
535+
536+
If both of you changed different parts, Git can merge them easily. But if you both changed the same part in different ways, Git won’t know which one to keep—that's called a conflict, and you'll need to resolve it manually.
537+
538+
![git-merging-behavior](imgs/git-merging-behavior.avif)
526539
</p>
527540
<p>
528-
Here are a few important things to know:
541+
Here are a few other things to know:
529542
</p>
530543
<ul>
531-
<li><strong>Merging propagates changes (diffs)</strong>: it does not transfer every element from one branch to another.</li>
532544
<li><strong>No conflicts ≠ no changes</strong>: “No conflicts” doesn’t mean “no changes” and it definitely doesn’t mean the project is error-free.</li>
533545
<li><strong>Project errors are not bugs</strong>: Project errors let you know that you are making mistakes when merging data. Even if changes are successfully merged, project errors indicate areas you should double-check to ensure everything merged as expected.</li>
534546
<li>If a change was previously accepted or rejected during a merge, it won’t appear as a diff the next time you merge the same branches. That’s expected behavior.</li>

0 commit comments

Comments
 (0)