You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/testing-deployment-publishing/branching-collaboration/branching.md
+15-3Lines changed: 15 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -522,13 +522,25 @@ YAML files play a key role in managing and resolving conflicts during the merge
522
522
Why didn’t all my changes appear after merging two branches?
523
523
</summary>
524
524
<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.
<li><strong>Merging propagates changes (diffs)</strong>: it does not transfer every element from one branch to another.</li>
532
544
<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>
533
545
<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>
534
546
<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