Add FAQ for Merging Behavior

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

@@ -515,4 +515,33 @@ YAML files play a key role in managing and resolving conflicts during the merge
 - YAML files allow you to manually edit and resolve conflicts during the merge process.
 - Since YAML files are text-based, they are version-controlled effectively, enabling multiple team members to make changes and merge their work.
 </p>
-</details>
+</details>
+
+<details>
+<summary>
+Why didn’t all my changes appear after merging two branches?
+</summary>
+<p>
+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.
+</p>
+<p>
+Here are a few important things to know:
+</p>
+<ul>
+  <li><strong>Merging propagates changes (diffs)</strong>: it does not transfer every element from one branch to another.</li>
+  <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>
+  <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>
+  <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>
+</ul>
+<p>
+
+For example, you merge `Branch B` into `Branch A`, and `change C` gets copied over. Later, you decide to undo `change C` directly on `Branch A`. Now, if you merge `Branch B` into `Branch A` again, Git will not re-flag `change C` as a difference. This is because Git considers it already merged and no longer a diff.
+
+</p>
+<p>
+
+<strong>Best Practice:</strong> Keep your branch histories short and simple. After each merge, delete the merged branch to avoid unnecessary complexity. For example, if you merge `Branch B` into `Branch A`, and later want to undo or revise those changes, don’t go back and modify `Branch B`. Instead, create a new branch (e.g., `Branch C`) from `Branch A` to make your updates.
+
+This approach prevents intertwining branch histories, avoids confusing merge behavior, and ensures clean, trackable diffs. Keeping branches focused and temporary makes merging more predictable and manageable.
+</p>
+</details>