{"id":1165,"date":"2026-09-19T06:42:45","date_gmt":"2026-09-19T06:42:45","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1165"},"modified":"2026-09-19T07:07:38","modified_gmt":"2026-09-19T07:07:38","slug":"git-git-branching-merging-a-complete-tutorials","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/git-git-branching-merging-a-complete-tutorials\/","title":{"rendered":"Git: Git Branching & Merging – A Complete Tutorials"},"content":{"rendered":"\n

PRACTICAL TECHNICAL HANDBOOK \/ 19 SEPTEMBER 2026<\/em><\/p>\n\n\n\n

Git Branching & Merging<\/h1>\n\n\n\n

Branch types, integration choices, conflicts and safe recovery<\/em><\/p>\n\n\n\n

Understand what Git changes, choose the right method, and verify the result. The scenario atlas pairs before-and-after graphs with runnable commands, trade-offs and the failure modes that matter.<\/p>\n\n\n\n

Navigate the handbook<\/h2>\n\n\n\n

01. The mental model and terminology<\/a><\/p>\n\n\n\n

02. Branch types and branching workflows<\/a><\/p>\n\n\n\n

03. Everyday commands and remote branches<\/a><\/p>\n\n\n\n

04. Choose an outcome and prepare the lab<\/a><\/p>\n\n\n\n

05. Merge scenario atlas: S01-S15<\/a><\/p>\n\n\n\n

06. Conflict resolution playbook<\/a><\/p>\n\n\n\n

07. Collaboration, pull requests and releases<\/a><\/p>\n\n\n\n

08. Recovery and troubleshooting<\/a><\/p>\n\n\n\n

Appendix A. Copyable Mermaid diagram source<\/a><\/p>\n\n\n\n

Appendix B. Official references and verification<\/a><\/p>\n\n\n\n

The five choices to recognize immediately<\/h2>\n\n\n\n
Desired outcome<\/strong><\/th>Reach for<\/strong><\/th><\/tr><\/thead>
Advance a target that has not diverged<\/td>git merge --ff-only topic<\/code><\/td><\/tr>
Keep both histories and record integration<\/td>git merge --no-ff topic<\/code><\/td><\/tr>
Deliver one commit per short-lived topic<\/td>git merge --squash topic<\/code>, then commit<\/td><\/tr>
Replay a private topic into a clean series<\/td>git rebase main<\/code>, then fast-forward<\/td><\/tr>
Move one independent fix to another line<\/td>git cherry-pick -x FIX_SHA<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Reading key.<\/strong> Commands in the scenario atlas are reproducible after loading the lab helper. Other command blocks are named recipes: adapt the stated branch, remote, file or commit names. Bracketed numbers point to references in Appendix B.<\/p>\n\n\n\n

01. The mental model<\/h2>\n\n\n\n

A commit<\/strong> records a snapshot and its parent commit(s). A branch<\/strong> is a movable name for a commit, not another copy of the project. A commit can be reachable from many branches; it does not permanently belong to the branch on which you first created it. [1, 2]<\/p>\n\n\n\n

flowchart LR\n  A[\"A\"] --> B[\"B<br\/>main\"] --> C[\"C<br\/>feature\/login\"]<\/code><\/pre>\n\n\n\n
Here, main<\/code> points to B and feature\/login<\/code> points to C. With HEAD<\/code> attached to feature\/login, a new commit advances feature\/login, not main. Diagram arrows show older-to-newer ancestry; actual commit objects refer back to their parents. [1]<\/p>\n\n\n\n
Term<\/strong><\/th>Meaning that matters in practice<\/strong><\/th><\/tr><\/thead>
HEAD<\/td>Your current position. Usually it refers to the checked-out local branch; in detached HEAD it names a commit directly.<\/td><\/tr>
Working tree<\/td>The files you are editing. Uncommitted edits are not permanently attached to a branch.<\/td><\/tr>
Index \/ staging area<\/td>The proposed next snapshot. git add<\/code> updates it; git commit<\/code> records it.<\/td><\/tr>
Reference \/ ref \/ tip<\/td>A ref names an object; a branch tip is the commit currently named by that branch.<\/td><\/tr>
Ancestor \/ descendant<\/td>A commit is an ancestor when you can reach it by walking parent links from another commit.<\/td><\/tr>
Merge base<\/td>A best common ancestor used for comparison. Complex histories can have more than one.<\/td><\/tr>
Source \/ target branch<\/td>Source supplies changes; target receives them. git merge topic<\/code> modifies the currently checked-out target.<\/td><\/tr>
Merge commit \/ first parent<\/td>A merge commit has multiple parents. The first is normally the previous tip of the branch receiving the merge.<\/td><\/tr>
DAG \/ tree<\/td>The history is a directed acyclic graph. A tree describes a snapshot of paths and content; identical trees need not imply identical history.<\/td><\/tr>
Tag \/ release<\/td>A tag identifies a chosen revision. Publishing or deploying a release is a separate workflow, not something a branch name proves.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Terminology and ancestry: [1, 2, 11, 12].<\/p>\n\n\n\n
edit files -> git add -> index -> git commit -> local branch\nlocal branch -> git push -> branch on the remote<\/code><\/pre>\n\n\n\n
The rule to remember.<\/strong> Switch to the destination<\/strong> before merging. git switch main<\/code> followed by git merge topic<\/code> means topic into main. Reversing the switch reverses the integration direction.<\/p>\n\n\n\n
02. Branch types: mechanism versus convention<\/h2>\n\n\n\n
Git has reference mechanisms and branch states. Teams add names such as feature, release and hotfix as conventions. The name alone does not change Git behavior. [1, 2]<\/p>\n\n\n\n
Form or state<\/strong><\/th>What it is<\/strong><\/th>Important distinction<\/strong><\/th><\/tr><\/thead>
Local branch<\/td>A writable local ref such as main<\/code> or feature\/login<\/code>.<\/td>Committing advances the checked-out branch.<\/td><\/tr>
Branch on a remote<\/td>A branch stored in another repository, commonly a server.<\/td>Push updates it subject to permissions and policy.<\/td><\/tr>
Remote-tracking ref<\/td>Your local last-observed view, such as origin\/main<\/code>.<\/td>Fetch refreshes it; it is not a live view of the server.<\/td><\/tr>
Tracking local branch<\/td>A local branch with an upstream association.<\/td>The association informs status and pull; it is not automatic synchronization.<\/td><\/tr>
Unborn \/ orphan branch<\/td>An unborn branch has no commit yet. An orphan start creates a new root history.<\/td>After its first commit it is a normal branch with independent ancestry. See S11.<\/td><\/tr>
Protected branch<\/td>A hosting-service rule applied to selected branches.<\/td>Review, checks and push restrictions are server policy, not a special Git branch object.<\/td><\/tr>
Detached HEAD<\/td>HEAD names a commit rather than a local branch.<\/td>Not a branch type. Name new work with git switch -c rescue\/work<\/code> before leaving it.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Reference mechanisms: [6, 9, 10]. Server protection: [20].<\/p>\n\n\n\n
Read the branch state<\/strong><\/p>\n\n\n\n
git branch                 # Local branches; * is current\ngit branch -r              # Remote-tracking refs\ngit branch -a              # Both views\ngit branch -vv             # Upstream and ahead\/behind summary\ngit remote -v              # Remote names and URLs<\/code><\/pre>\n\n\n\n
Create a tracking branch or set its upstream<\/strong><\/p>\n\n\n\n
These are separate recipes. The remote branch must already exist for the first one.<\/p>\n\n\n\n
git fetch origin\ngit switch --track -c feature\/login origin\/feature\/login\n\n# Existing local branch: change its upstream association.\ngit branch --set-upstream-to=origin\/feature\/login feature\/login<\/code><\/pre>\n\n\n\n
Three meanings people confuse.<\/strong> origin<\/code> is a conventional remote name. An upstream branch<\/strong> is a configured tracking relationship. A remote literally named upstream<\/code> is merely another remote, often the original project in a fork workflow. [6, 9]<\/p>\n\n\n\n
A fork<\/strong> is another repository, not another branch. A worktree<\/strong> is another working directory attached to the same repository; it is useful for keeping two branches checked out separately. [19, 22]<\/p>\n\n\n\n
Branch roles used by teams<\/h3>\n\n\n\n
Choose roles because the delivery process needs them, not because Git requires them. main<\/code>, master<\/code> and trunk<\/code> can all be names for the principal line. The lifecycle below is a recommended naming convention, not a built-in taxonomy.<\/p>\n\n\n\n
Role \/ example<\/strong><\/th>Start from -> integrate into<\/strong><\/th>Benefit and cost<\/strong><\/th><\/tr><\/thead>
Main \/ trunk<\/td>Principal integration line; protect it.<\/td>One authoritative integration point; requires a clear quality gate.<\/td><\/tr>
Develop \/ integration<\/td>Usually main initially; receives features in Gitflow.<\/td>Separates next-release work; adds another permanent line to maintain.<\/td><\/tr>
Feature \/ topic<\/td>Current main, or develop in Gitflow -> that base.<\/td>Isolates one change; long-lived topics accumulate integration risk.<\/td><\/tr>
Bugfix \/ fix<\/td>The affected active line -> the same line.<\/td>Focused repair; choosing the wrong base can import unrelated code.<\/td><\/tr>
Hotfix<\/td>Exact deployed tag \/ supported release -> affected release and active development.<\/td>Fast, isolated production repair; every affected line still needs the fix.<\/td><\/tr>
Release<\/td>Approved integration point -> release and necessary back-merges.<\/td>Allows stabilization; needs a freeze policy and fix propagation.<\/td><\/tr>
Maintenance \/ support<\/td>Released tag -> supported version line.<\/td>Supports older versions; each maintained line adds backport and testing cost.<\/td><\/tr>
Experiment \/ spike<\/td>Any explicit base -> merge only if adopted.<\/td>Safe exploration; abandoned experiments must not become hidden dependencies.<\/td><\/tr>
Chore \/ docs \/ refactor \/ test<\/td>The active integration line -> that line.<\/td>Useful intent labels; they are still ordinary topic branches.<\/td><\/tr>
Environment branch<\/td>A team-defined line such as staging.<\/td>Can support a deliberate promotion model; risks drift and environment-only fixes.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Creation recipes<\/strong><\/p>\n\n\n\n
Run these independently. main<\/code> must exist; v1.2.0<\/code> must be a real released tag. In Gitflow, use develop rather than main where the team requires it. [6, 10, 24]<\/p>\n\n\n\n
git switch -c develop main\ngit switch -c feature\/login main\ngit switch -c bugfix\/login-error main\ngit switch -c hotfix\/1.2.1 v1.2.0\ngit switch -c release\/1.3 main\ngit switch -c support\/1.2 v1.2.0\ngit switch -c experiment\/cache main\ngit switch -c chore\/dependencies main\ngit switch -c docs\/install main\ngit switch -c refactor\/auth main\ngit switch -c test\/login main\ngit switch -c staging main<\/code><\/pre>\n\n\n\n
Choose a branching workflow<\/h3>\n\n\n\n
A branching workflow<\/strong> decides which lines exist and how long they live. A merge method<\/strong> decides how one integration changes history. Choose them separately; Gitflow does not require every merge to use the same flag.<\/p>\n\n\n\n
Workflow<\/strong><\/th>Structure and good fit<\/strong><\/th>Strength<\/strong><\/th>Cost \/ risk<\/strong><\/th><\/tr><\/thead>
Trunk-based<\/td>One principal line; very short-lived changes, often with feature flags. Useful for frequent delivery.<\/td>Small integration gaps and rapid feedback.<\/td>Requires strong checks, small changes and discipline around incomplete work.<\/td><\/tr>
GitHub flow<\/td>Short-lived branch -> review \/ checks -> main. Useful for simple continuous-delivery teams.<\/td>Easy to explain and automate.<\/td>Supported old releases need an additional explicit policy.<\/td><\/tr>
Gitflow<\/td>main + develop + feature, release and hotfix branches. Useful for planned, versioned releases.<\/td>Clear release-stabilization structure.<\/td>More synchronization paths; often excessive for continuously deployed services.<\/td><\/tr>
Release \/ maintenance lines<\/td>main plus selected supported version branches. Useful when multiple versions remain active.<\/td>Isolates version-specific fixes.<\/td>Backport selection and per-version testing are ongoing work.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Workflow definitions and trade-offs: [22, 23, 24]. The Gitflow author also recommends simpler workflows for continuously delivered web applications. [24]<\/p>\n\n\n\n
A practical default policy<\/strong><\/p>\n\n\n\n
For a new web application, start with protected main and short-lived topics. Choose squash when a pull request is the delivery unit, or preserve well-structured commits through merges or rebase-and-fast-forward. Add release branches only when actual release support requires them. This is a starting recommendation, not a universal rule.<\/p>\n\n\n\n
Branch names are not deployment evidence<\/strong><\/p>\n\n\n\n
A branch called production can move without a deployment, and a deployment can use a tag or commit without moving a branch. Record the deployed commit and artifact identity. Where practical, promote the same built artifact through environments rather than rebuilding different code from environment branches.<\/p>\n\n\n\n
Keep the model small<\/strong><\/p>\n\n\n\n
Question<\/strong><\/th>Decision to record<\/strong><\/th><\/tr><\/thead>
Where does new work start?<\/td>main, develop, or an explicitly supported release line.<\/td><\/tr>
What is the review unit?<\/td>One logical commit, one topic branch, or one pull request.<\/td><\/tr>
Who may rewrite a topic?<\/td>Its owner, with explicit coordination if it is already shared.<\/td><\/tr>
How do fixes propagate?<\/td>Merge the shared history or cherry-pick an independent fix; test each target.<\/td><\/tr>
When is a branch deleted?<\/td>After integration is verified and no other work depends on it.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
03. Everyday branching and remote commands<\/h2>\n\n\n\n
Start one piece of work<\/strong><\/p>\n\n\n\n
Recipe for an existing clone with origin and main. Start clean; do not run this over unrelated uncommitted work.<\/p>\n\n\n\n
git status --short\ngit fetch --prune origin\ngit switch main\ngit merge --ff-only origin\/main\ngit switch -c feature\/login\n# Edit the intended files, then stage only those files.\ngit add -- path\/to\/changed-file\ngit diff --cached\ngit commit -m \"feat: add login flow\"\ngit push -u origin feature\/login<\/code><\/pre>\n\n\n\n
Replace path\/to\/changed-file<\/code> with a real changed path. -u<\/code> sets the upstream after a successful push. In a protected repository, finish through a reviewed pull request rather than pushing directly to main. [6, 9, 20]<\/p>\n\n\n\n
Action<\/strong><\/th>What changes<\/strong><\/th>What does not happen automatically<\/strong><\/th><\/tr><\/thead>
fetch<\/td>Downloads objects and refreshes applicable remote-tracking refs.<\/td>Does not integrate those changes into your current local branch.<\/td><\/tr>
pull<\/td>Fetches, then integrates into the current branch using the chosen mode.<\/td>Does not choose the correct branch or policy for your team.<\/td><\/tr>
push<\/td>Requests remote ref updates using your local commits.<\/td>Does not first fetch and merge someone else’s changes.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Use explicit pull modes rather than relying on machine-specific defaults. [9, 15]<\/p>\n\n\n\n
git pull --ff-only     # Refuse if the local branch diverged.\ngit pull --rebase      # Replay local work; changes history.\ngit pull --no-rebase   # Integrate by merge; FF if permitted.<\/code><\/pre>\n\n\n\n
Rename and clean up deliberately<\/strong><\/p>\n\n\n\n
# Rename an existing local branch; coordinate shared names.\ngit branch -m old-name new-name\ngit push -u origin new-name\n\n# After integration has been verified, leave the topic first.\ngit switch main\ngit branch -d feature\/login\ngit push origin --delete feature\/login\ngit fetch --prune origin<\/code><\/pre>\n\n\n\n
Deletion is two separate actions.<\/strong> git branch -d<\/code> is local; git push origin --delete<\/code> changes the server. Fetch pruning removes stale remote-tracking refs, not your local branches. After a squash, verify delivery and dependencies before deliberately using -D<\/code>; do not force deletion simply to silence the safety check. [6, 9]<\/p>\n\n\n\n
04. Inspect history and choose the outcome<\/h2>\n\n\n\n
Read the graph, not just the file diff<\/strong><\/p>\n\n\n\n
git log --oneline --graph --decorate --all\ngit log main..topic                 # Commits only on topic\ngit log --left-right --oneline main...topic\ngit diff main topic                # Compare the two tip trees\ngit diff main...topic              # Merge base -> topic tree\ngit diff --cached --check          # Staged whitespace\/marker checks<\/code><\/pre>\n\n\n\n
For log<\/strong>, two dots select commits reachable from the right but not the left; three dots select the symmetric difference. For diff<\/strong>, three dots compare the merge base with the right-hand tip. Do not assume log and diff interpret the notation identically. [12, 16]<\/p>\n\n\n\n
Method<\/strong><\/th>Original source commits<\/strong><\/th>New integration commit<\/strong><\/th>Best reason to choose it<\/strong><\/th><\/tr><\/thead>
Fast-forward<\/td>Kept unchanged<\/td>None<\/td>Advance an already-compatible target.<\/td><\/tr>
Normal \/ –no-ff merge<\/td>Kept unchanged<\/td>A multi-parent merge, unless no-op \/ permitted FF<\/td>Preserve shared history and integration ancestry.<\/td><\/tr>
Squash merge<\/td>Remain on source; not linked as merged parents<\/td>One ordinary commit after you commit<\/td>Make one topic the delivery unit.<\/td><\/tr>
Rebase + FF<\/td>Replayed commits get new IDs when rewritten<\/td>No merge commit<\/td>Publish a clean, private patch series.<\/td><\/tr>
Cherry-pick<\/td>Source stays; selected patch is copied<\/td>Usually one ordinary commit per pick<\/td>Move a particular independent fix.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
A fast-forward does not flatten merge commits that already exist in the source history. The table describes the integration step, not a guarantee that the entire graph is linear. [3-7]<\/p>\n\n\n\n
Methods are not algorithms<\/strong><\/p>\n\n\n\n
Algorithm \/ option<\/strong><\/th>Meaning<\/strong><\/th><\/tr><\/thead>
ort<\/td>Current default for a two-head merge; handles common-base comparison and rename detection.<\/td><\/tr>
recursive<\/td>Historical implementation; since Git 2.50 it is an alias for ort. Older installations differ.<\/td><\/tr>
resolve<\/td>Older two-head strategy without rename handling; rarely needed for routine work.<\/td><\/tr>
octopus<\/td>Combines multiple topic heads; refuses complex manual conflict resolution.<\/td><\/tr>
ours \/ subtree<\/td>Special history-preserving or layout-aware strategies. See S13 \/ S14.<\/td><\/tr>
-s versus -X<\/td>-s<\/code> selects a strategy; -X<\/code> supplies an option to it. Squash, –ff and –no-ff are not strategy names.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Algorithm details: [8].<\/p>\n\n\n\n
Prepare the disposable learning lab<\/h3>\n\n\n\n
Run the helper below once in Bash or Zsh<\/strong>: macOS, Linux, or Git Bash on Windows. Every lab MODE<\/code> call creates and enters a new temporary repository. It never reuses your project directory. Git 2.34+ covers the commands used here; the examples were executed with Git 2.47.3.<\/p>\n\n\n\n
lab() {\n  case \"$1\" in\n    base|ff|split|conflict) ;;\n    *) echo 'Use: lab base|ff|split|conflict'; return 1 ;;\n  esac\n  cd \"$(mktemp -d \"${TMPDIR:-\/tmp}\/git-lab.XXXXXX\")\" || return\n  git init -q -b main\n  git config user.name 'Git Learner'\n  git config user.email 'learner@example.invalid'\n  git config commit.gpgsign false\n  git config merge.ff true\n  git config rerere.enabled false\n  printf 'color=blue\\n' > app.txt\n  git add app.txt; git commit -qm A\n  git branch base\n  [ \"$1\" = base ] && return 0\n  git switch -q -c topic\n  if [ \"$1\" = conflict ]; then\n    printf 'color=green\\n' > app.txt\n  else\n    printf 'feature\\n' > feature.txt\n  fi\n  git add .; git commit -qm B\n  printf 'tests\\n' > test.txt\n  git add test.txt; git commit -qm C\n  git switch -q main\n  if [ \"$1\" != ff ]; then\n    if [ \"$1\" = conflict ]; then\n      printf 'color=red\\n' > app.txt\n    else\n      printf 'guide\\n' > guide.txt\n    fi\n    git add .; git commit -qm D\n  fi\n  printf 'Disposable lab: %s\\n' \"$PWD\"\n}<\/code><\/pre>\n\n\n\n
Mode<\/strong><\/th>Starting history<\/strong><\/th><\/tr><\/thead>
lab base<\/code><\/td>Only A on main. A helper branch named base stays at A.<\/td><\/tr>
lab ff<\/code><\/td>main at A; topic adds B and C.<\/td><\/tr>
lab split<\/code><\/td>main adds D; topic adds B and C in separate files.<\/td><\/tr>
lab conflict<\/code><\/td>main changes app.txt to red; topic changes it to green, then adds test.txt.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
All graphs omit the helper base ref. Letters are commit-message labels, not literal hashes. The scenarios are independent: always run their first lab command. Expected conflicts and refusals are intentional; do not run those blocks inside a shell configured to exit on the first non-zero command.<\/p>\n\n\n\n
05. Merge scenario atlas<\/h2>\n\n\n\n
S01 | Fast-forward: move the branch pointer<\/h3>\n\n\n\n
EVERYDAY<\/em><\/p>\n\n\n\n
Use this when main has not gained its own commits since topic branched off. The target can move from A to C without creating a new commit.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A<br\/>main\"] --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aB[\"B\"] --> aC[\"C<br\/>main + topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S01<\/a><\/p>\n\n\n\n
lab ff\ngit switch main\ngit merge --ff-only topic\ngit log --oneline --graph --decorate --all<\/code><\/pre>\n\n\n\n
Result.<\/strong> main and topic now point to C. B and C keep their identities; no merge commit exists. Only main moved during the merge.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Small, linear history; original commits remain intact; refusal protects a fast-forward-only policy.<\/td>No explicit integration boundary. It cannot combine two diverged tips.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> Fast-forward does not mean one commit or squashed commits. Every commit already on topic remains in history.<\/p>\n\n\n\n
git rev-parse main topic<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Both lines print the same commit ID.<\/p>\n\n\n\n
Reference: [3, 4]<\/p>\n\n\n\n
S02 | Force a merge commit with –no-ff<\/h3>\n\n\n\n
EVERYDAY<\/em><\/p>\n\n\n\n
Use this when the history is fast-forwardable, but the team wants an explicit record that a topic was integrated.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A<br\/>main\"] --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aB[\"B\"] --> aC[\"C<br\/>topic\"] --> aM[\"M<br\/>main\"]\n  aA --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S02<\/a><\/p>\n\n\n\n
lab ff\ngit switch main\ngit merge --no-ff topic -m \"M: integrate topic\"\ngit show -s --format='%h %p %s' HEAD<\/code><\/pre>\n\n\n\n
Result.<\/strong> M has two parents: A first, C second. The source branch stays at C. The snapshot includes the topic changes.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Preserves original commits and a visible feature boundary. First-parent logs give a concise integration timeline.<\/td>Adds a commit even when pointer movement would suffice; heavy use can clutter a small repository.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> –no-ff does not manufacture a merge when the input is already an ancestor of HEAD. That case is still a no-op.<\/p>\n\n\n\n
git log --first-parent --oneline main<\/code><\/pre>\n\n\n\n
Expected:<\/strong> M appears as the integration step on main.<\/p>\n\n\n\n
Reference: [3, 4]<\/p>\n\n\n\n
S03 | Three-way merge: both branches advanced<\/h3>\n\n\n\n
EVERYDAY<\/em><\/p>\n\n\n\n
main contains D while topic contains B and C. A is their common ancestor. Git combines the changes from A to D with those from A to C.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S03<\/a><\/p>\n\n\n\n
lab split\ngit switch main\ngit merge topic -m \"M: combine both histories\"\ngit show -s --format='%h %p %s' HEAD<\/code><\/pre>\n\n\n\n
Result.<\/strong> M joins D and C. Both histories remain reachable. This lab merges cleanly because the sides add different files.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Keeps shared history stable and preserves both lines of development; appropriate for collaboratively edited branches.<\/td>Creates a non-linear history; unrelated-looking edits can still interact badly at runtime.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> A three-way merge is not a three-parent merge. It compares a base and two tips, usually producing a two-parent commit.<\/p>\n\n\n\n
git diff HEAD^1 HEAD --stat<\/code><\/pre>\n\n\n\n
Expected:<\/strong> The diff shows what this integration added relative to the previous main tip.<\/p>\n\n\n\n
Reference: [3, 4, 12]<\/p>\n\n\n\n
S04 | Three-way merge with a conflict<\/h3>\n\n\n\n
EVERYDAY<\/em><\/p>\n\n\n\n
Both branches change the same setting differently: main wants red; topic wants green. Git stops for a human decision. The after graph exists only after resolution and commit.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S04<\/a><\/p>\n\n\n\n
lab conflict\ngit merge topic\n# Expected conflict: inspect before deciding.\ngit status --short\ncat app.txt\n# Lab decision: the agreed final value is purple.\nprintf 'color=purple\\n' > app.txt\ngit add app.txt\ngit diff --cached --check\ngit commit -m \"M: resolve color deliberately\"<\/code><\/pre>\n\n\n\n
Result.<\/strong> During the conflict, HEAD remains at D and no M exists. After committing, M has D and C as parents and contains the chosen resolution.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Preserves both histories and makes the integration decision reviewable.<\/td>Requires judgment and regression tests; choosing a side blindly can discard valid behavior.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> git add marks a path resolved; it does not prove the result is correct. To abandon an ordinary in-progress merge, use git merge –abort.<\/p>\n\n\n\n
git status --short\ngit show HEAD:app.txt<\/code><\/pre>\n\n\n\n
Expected:<\/strong> The status is clean and the file contains color=purple.<\/p>\n\n\n\n
Reference: [4, 13]<\/p>\n\n\n\n
S05A | Already up to date: nothing to merge<\/h3>\n\n\n\n
GUARDRAIL<\/em><\/p>\n\n\n\n
Every commit reachable from topic is already reachable from main. Repeating the merge changes nothing; the tips need not be equal for this rule to hold.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bB[\"B\"] --> bC[\"C<br\/>main + topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aB[\"B\"] --> aC[\"C<br\/>main + topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S05A<\/a><\/p>\n\n\n\n
lab ff\ngit merge --ff-only topic   # Prepare the BEFORE graph.\ngit merge topic             # Already up to date.<\/code><\/pre>\n\n\n\n
Result.<\/strong> No commit is created and neither pointer moves.<\/p>\n\n\n\n
Pros:<\/strong> Safe and idempotent. Cons:<\/strong> It checks ancestry, not whether a past change was later reverted.<\/p>\n\n\n\n
Watch out.<\/strong> After a revert or an ours-strategy merge, Git can say this even though the files do not contain the topic behavior.<\/p>\n\n\n\n
Reference: [4, 11]<\/p>\n\n\n\n
S05B | Fast-forward-only refuses divergence<\/h3>\n\n\n\n
GUARDRAIL<\/em><\/p>\n\n\n\n
The target and source each have unique commits. –ff-only refuses rather than choosing a merge or rebase for you.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S05B<\/a><\/p>\n\n\n\n
lab split\ngit merge --ff-only topic   # Expected non-zero exit.\ngit status --short<\/code><\/pre>\n\n\n\n
Result.<\/strong> The committed graph and branch pointers stay unchanged. This is a policy refusal, not a merge conflict.<\/p>\n\n\n\n
Pros:<\/strong> Prevents accidental merge commits. Cons:<\/strong> You must deliberately select another integration method.<\/p>\n\n\n\n
Watch out.<\/strong> Do not answer this error with reset –hard or force-push. Choose a normal merge or a permitted rebase after inspecting the graph.<\/p>\n\n\n\n
Reference: [4]<\/p>\n\n\n\n
S06 | Squash merge: one delivery commit<\/h3>\n\n\n\n
EVERYDAY<\/em><\/p>\n\n\n\n
Use this when a short-lived topic contains useful work but noisy intermediate commits. The destination receives one ordinary commit containing the combined result.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aS[\"S<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S06<\/a><\/p>\n\n\n\n
lab split\ngit merge --squash topic\ngit diff --cached\ngit diff --cached --check\ngit commit -m \"S: deliver feature and tests\"<\/code><\/pre>\n\n\n\n
Result.<\/strong> S has only D as its parent. There is deliberately no ancestry edge from C to S. B and C still exist on topic, but not as its merged ancestors.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
One reviewable delivery unit; concise main history; easy to revert the complete change as an ordinary commit.<\/td>Loses per-commit detail on main and does not record topic ancestry. Reusing the old topic can repeat changes or conflicts.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> –squash does not commit for you and does not set MERGE_HEAD. Use a fresh branch from updated main for the next task. git branch -d may refuse the old topic.<\/p>\n\n\n\n
git show -s --format=%p HEAD<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Exactly one parent ID is printed. Do not treat ancestry checks as squash-verification checks.<\/p>\n\n\n\n
Reference: [4, 21]<\/p>\n\n\n\n
S07 | Rebase, then fast-forward<\/h3>\n\n\n\n
EVERYDAY – REWRITES TOPIC<\/em><\/p>\n\n\n\n
Rebase replays the topic commits on top of current main; then a fast-forward integrates the replayed series. Rebase itself is not a merge.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aBP[\"B'\"] --> aCP[\"C'<br\/>main + topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S07<\/a><\/p>\n\n\n\n
lab split\ngit switch topic\ngit branch backup\/topic-before-rebase\ngit rebase main\ngit switch main\ngit merge --ff-only topic<\/code><\/pre>\n\n\n\n
Result.<\/strong> D is followed by B’ and C’. These replayed commits have new identities. The backup still retains B and C; it is omitted from the diagram.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Linear main history while retaining separate logical commits; useful for a privately owned, well-organized topic.<\/td>Rewrites the topic; conflicts can recur per replayed commit; coordinating already-published history takes extra care.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> Do not rebase shared main or surprise collaborators on a shared topic. A no-op rebase need not recreate commits; the changed-parent example here does.<\/p>\n\n\n\n
git log --oneline --graph main<\/code><\/pre>\n\n\n\n
Expected:<\/strong> The main line is A, D, B’, C’ with no merge commit.<\/p>\n\n\n\n
Reference: [5, 6]<\/p>\n\n\n\n
S08 | Cherry-pick: bring across one change<\/h3>\n\n\n\n
SELECTIVE INTEGRATION<\/em><\/p>\n\n\n\n
Use this to backport a specific fix without importing its entire source branch. Here B adds feature.txt independently; C adds unrelated tests and is intentionally not selected.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aBP[\"B'<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S08<\/a><\/p>\n\n\n\n
lab split\ngit switch main\ngit show topic~1 --stat\ngit cherry-pick -x topic~1<\/code><\/pre>\n\n\n\n
Result.<\/strong> A new B’ follows D. The source still points to C. There is no merge-parent edge between the two lines; cherry-pick is not a history merge.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Precise selection; useful across supported release lines; -x records the source commit for traceability in the clean example.<\/td>Can omit dependencies or tests; creates parallel patch histories and extra maintenance work.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> Inspect prerequisites first. A fix may require earlier commits or a release-specific adaptation. -x does not make the source an ancestor.<\/p>\n\n\n\n
git show --stat HEAD\ngit log -1 --format=%B<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Only B’s selected change is applied and the message includes its source commit.<\/p>\n\n\n\n
Reference: [7]<\/p>\n\n\n\n
S09 | Merge main into a feature branch<\/h3>\n\n\n\n
EVERYDAY – SYNC DIRECTION<\/em><\/p>\n\n\n\n
Use this to update a shared topic without rewriting it. The target is topic, so the merge belongs on topic, not on main.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D<br\/>main\"] --> aM[\"M<br\/>topic\"]\n  aA --> aB[\"B\"] --> aC[\"C\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S09<\/a><\/p>\n\n\n\n
lab split\ngit switch topic\ngit merge main -m \"M: sync main into topic\"\ngit show -s --format='%h %p %s' HEAD<\/code><\/pre>\n\n\n\n
Result.<\/strong> M has C as its first parent and D as its second. main remains at D. Integrating main into topic does not deliver topic into main.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Safe for shared topic history; conflicts are addressed before final review; no forced update is needed.<\/td>Repeated syncs add merge commits to the feature history; frequent small integrations are easier to review.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> In a real clone, fetch and merge origin\/main when local main may be stale. Recheck the destination branch before every merge.<\/p>\n\n\n\n
git rev-parse main\ngit rev-parse topic^1 topic^2<\/code><\/pre>\n\n\n\n
Expected:<\/strong> main still names D; the two parent lines name C and D, respectively.<\/p>\n\n\n\n
Reference: [4, 9]<\/p>\n\n\n\n
S10 | Octopus: merge several independent topics<\/h3>\n\n\n\n
SPECIALIZED<\/em><\/p>\n\n\n\n
An octopus merge bundles multiple topic heads into one integration commit. Use it only for independent changes that merge without complex manual resolution.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B<br\/>feature\/ui\"]\n  bA --> bC[\"C<br\/>feature\/api\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aA --> aB[\"B<br\/>feature\/ui\"] --> aM\n  aA --> aC[\"C<br\/>feature\/api\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S10<\/a><\/p>\n\n\n\n
lab base\ngit switch -c feature\/ui\nprintf 'ui\\n' > ui.txt\ngit add ui.txt; git commit -m B\ngit switch -c feature\/api base\nprintf 'api\\n' > api.txt\ngit add api.txt; git commit -m C\ngit switch main\nprintf 'ops\\n' > ops.txt\ngit add ops.txt; git commit -m D\ngit merge --no-ff feature\/ui feature\/api -m M<\/code><\/pre>\n\n\n\n
Result.<\/strong> M has three parents in this example: D, B and C. Both feature branch pointers remain unchanged.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
One integration point for several independent topics.<\/td>Harder to review or partially revert. The octopus strategy refuses complex merges needing manual conflict resolution.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> Several regular two-branch merges are usually clearer for application teams. This is not the meaning of a three-way merge.<\/p>\n\n\n\n
git show -s --format=%p HEAD<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Three parent IDs are printed.<\/p>\n\n\n\n
Reference: [8]<\/p>\n\n\n\n
S11 | Merge histories with no common ancestor<\/h3>\n\n\n\n
SPECIALIZED<\/em><\/p>\n\n\n\n
Use this only for an intentional repository-history import. Git normally refuses histories that share no ancestor.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bX[\"X<br\/>imported\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aX[\"X<br\/>imported\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S11<\/a><\/p>\n\n\n\n
lab base\ngit switch --orphan imported\nprintf 'Imported project\\n' > IMPORTED.md\ngit add IMPORTED.md; git commit -m X\ngit switch main\nprintf 'Local guide\\n' > guide.txt\ngit add guide.txt; git commit -m D\ngit merge --allow-unrelated-histories --no-ff \\\n  imported -m \"M: import independent history\"<\/code><\/pre>\n\n\n\n
Result.<\/strong> M connects the formerly separate roots. The example keeps both projects at the repository root because their file names do not collide.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Preserves the imported history in one repository.<\/td>Can create add\/add conflicts or a confusing layout; licensing, provenance and sensitive-history review are separate requirements.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> Do not use this flag to bypass a wrong remote, wrong repository, or incomplete shallow fetch. An orphan branch is not automatically safe to merge.<\/p>\n\n\n\n
git rev-list --max-parents=0 main<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Two root commit IDs are reachable from main.<\/p>\n\n\n\n
Reference: [4, 10]<\/p>\n\n\n\n
S12 | Prefer a side for conflicting hunks: -X<\/h3>\n\n\n\n
SPECIALIZED – REVIEW CAREFULLY<\/em><\/p>\n\n\n\n
-X ours or -X theirs changes how the normal merge resolves conflicting hunks. Non-conflicting changes from both sides still participate. Both choices produce the same ancestry graph below.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S12<\/a><\/p>\n\n\n\n
lab conflict\ngit merge --no-ff -s ort -X ours topic -m M\ncat app.txt        # color=red\ncat test.txt       # tests: incoming clean change kept\n\n# Alternative: repeat in a NEW lab, not the merged one.\nlab conflict\ngit merge --no-ff -s ort -X theirs topic -m M\ncat app.txt        # color=green\ncat test.txt       # tests: still present<\/code><\/pre>\n\n\n\n
Result.<\/strong> With ours, M keeps red for the conflicting line. With theirs, M keeps green. Both retain test.txt from the incoming topic.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Useful when a reviewed policy genuinely decides conflicts of this kind.<\/td>Can silently choose the wrong behavior. Some structural conflicts still require intervention.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> -X ours is not -s ours, and -s theirs is not a built-in strategy. During rebase, the usual intuitive meaning of ours\/theirs is reversed; see the conflict playbook.<\/p>\n\n\n\n
git show -s --format=%p HEAD<\/code><\/pre>\n\n\n\n
Expected:<\/strong> The selected variant has a normal two-parent merge commit.<\/p>\n\n\n\n
Reference: [8, 13]<\/p>\n\n\n\n
S13 | Record ancestry but keep our whole tree<\/h3>\n\n\n\n
SPECIALIZED – HIGH RISK<\/em><\/p>\n\n\n\n
The ours strategy records the other history as merged while keeping the destination snapshot unchanged. It is a deliberate history-management operation, not normal conflict resolution.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S13<\/a><\/p>\n\n\n\n
lab split\ngit merge --no-ff -s ours topic \\\n  -m \"M: supersede topic without taking its files\"\ngit diff HEAD^1 HEAD\ngit merge-base --is-ancestor topic HEAD<\/code><\/pre>\n\n\n\n
Result.<\/strong> M has two parents, but its tree equals D exactly. Neither feature.txt nor test.txt is taken from topic. Future merges consider C already integrated.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Can retire or supersede a history deliberately while preserving the ancestry record.<\/td>Drops all incoming content, including non-conflicting work; may prevent later merges from introducing changes you actually wanted.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> An ancestry check returning success is not proof that the source behavior exists in the target. Never use -s ours as a convenient conflict shortcut.<\/p>\n\n\n\n
git diff --exit-code HEAD^1 HEAD<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Exit status 0 and no output: the destination tree did not change.<\/p>\n\n\n\n
Reference: [8, 11]<\/p>\n\n\n\n
S14 | Subtree-aware merge: align directory layouts<\/h3>\n\n\n\n
SPECIALIZED<\/em><\/p>\n\n\n\n
Use a subtree-aware merge when the incoming project root corresponds to a subdirectory in the destination. Here app.txt lives at the vendor root, but under vendor\/widget on main.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bV[\"V<br\/>vendor\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M<br\/>main\"]\n  aA --> aV[\"V<br\/>vendor\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S14<\/a><\/p>\n\n\n\n
lab base\ngit switch -c vendor base\nprintf 'color=green\\n' > app.txt\ngit commit -am \"V: update vendor file\"\ngit switch main\nmkdir -p vendor\/widget\ngit mv app.txt vendor\/widget\/app.txt\ngit commit -m \"D: place library in a subdirectory\"\ngit merge --no-ff -s ort -Xsubtree=vendor\/widget \\\n  vendor -m \"M: align vendor layout\"\ncat vendor\/widget\/app.txt<\/code><\/pre>\n\n\n\n
Result.<\/strong> M keeps the destination layout and applies the vendor update under vendor\/widget. The file there contains color=green; no root app.txt is created.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Accommodates intentional directory-layout differences while retaining history.<\/td>Requires correct prefix mapping and review of rename\/path behavior. A wrong mapping can produce an unwanted tree.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> -s subtree guesses alignment; -Xsubtree=PATH makes the mapping explicit with ort. Neither is the separate git subtree add\/pull workflow or a submodule.<\/p>\n\n\n\n
git ls-tree -r --name-only HEAD<\/code><\/pre>\n\n\n\n
Expected:<\/strong> The file appears at vendor\/widget\/app.txt.<\/p>\n\n\n\n
Reference: [8]<\/p>\n\n\n\n
S15 | Interactive rebase: polish before integration<\/h3>\n\n\n\n
HISTORY EDITING – PRIVATE TOPIC<\/em><\/p>\n\n\n\n
Use interactive rebase to reorder, edit, combine or remove private topic commits intentionally. In this example, keep B as pick and change the line for C from pick to fixup in the editor, then save and close.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"]\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aS[\"S<br\/>main + topic\"]\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: S15<\/a><\/p>\n\n\n\n
lab split\ngit switch topic\ngit branch backup\/topic-before-edit\ngit rebase -i main\n# Save the todo list: pick B, then fixup C.\ngit switch main\ngit merge --ff-only topic<\/code><\/pre>\n\n\n\n
Result.<\/strong> S combines the changes from B and C on top of D and keeps the B message. Both main and topic move to this rewritten series. The backup still retains the old topic and is omitted above.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Produces intentional, reviewable commits before publication; fixup removes correction noise without keeping every intermediate message.<\/td>Rewrites the topic. Dropping or reordering commits can remove behavior or violate dependencies; reviewers must inspect the rewritten result.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> This differs from git merge –squash: interactive rebase rewrites the source branch itself. Use squash instead of fixup in the todo list when you need to combine and edit commit messages.<\/p>\n\n\n\n
git log --oneline main\ngit show --stat HEAD<\/code><\/pre>\n\n\n\n
Expected:<\/strong> The main line is A, D, S; S contains both feature.txt and test.txt.<\/p>\n\n\n\n
Reference: [5, 29]<\/p>\n\n\n\n
06. Conflict resolution: inspect, decide, finish<\/h2>\n\n\n\n
A conflict means Git cannot safely choose a result mechanically. It does not mean either branch is wrong. First establish the intended behavior; then edit, stage, test and complete the correct operation. [13, 30]<\/p>\n\n\n\n
Use the base to understand both changes<\/strong><\/p>\n\n\n\n
git config merge.conflictStyle diff3\n# Set before starting the merge; diff3 includes the base text.<\/code><\/pre>\n\n\n\n
<<<<<<< HEAD\ncolor=red\n||||||| base\ncolor=blue\n=======\ncolor=green\n>>>>>>> topic<\/code><\/pre>\n\n\n\n
In an ordinary merge, the top section is your current target, the middle is the common base, and the bottom is the incoming source. The correct result may be either side or a new combined solution. Remove all markers after deciding. [4, 13]<\/p>\n\n\n\n
A reliable resolution sequence<\/strong><\/p>\n\n\n\n
git status\ngit diff --name-only --diff-filter=U\ngit ls-files -u\ngit show :1:app.txt       # Base version, if present\ngit show :2:app.txt       # Ours in this ordinary merge\ngit show :3:app.txt       # Theirs in this ordinary merge\n# Edit app.txt to the intended final content.\ngit add -- app.txt\ngit diff --cached\ngit diff --cached --check\n# Run the relevant build and tests before completion.\ngit merge --continue<\/code><\/pre>\n\n\n\n
Some conflict types do not have all three index stages. git diff --cached --check<\/code> can catch whitespace errors and conflict markers; it cannot validate application behavior. [13, 16]<\/p>\n\n\n\n
Operation in progress<\/strong><\/th>Complete after resolving<\/strong><\/th>Cancel<\/strong><\/th><\/tr><\/thead>
Ordinary merge<\/td>git merge --continue<\/code><\/td>git merge --abort<\/code><\/td><\/tr>
Rebase<\/td>git rebase --continue<\/code><\/td>git rebase --abort<\/code><\/td><\/tr>
Cherry-pick<\/td>git cherry-pick --continue<\/code><\/td>git cherry-pick --abort<\/code><\/td><\/tr>
Revert<\/td>git revert --continue<\/code><\/td>git revert --abort<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Do not skip a commit to escape a conflict.<\/strong> git rebase --skip<\/code> and git cherry-pick --skip<\/code> omit the current patch. Use them only after proving that omission is intentional. --quit<\/code> is not equivalent to aborting and restoring the previous state. [5, 7, 14]<\/p>\n\n\n\n
Conflict types and side-selection traps<\/h3>\n\n\n\n
Conflict<\/strong><\/th>What you must decide<\/strong><\/th>Typical action after deciding<\/strong><\/th><\/tr><\/thead>
Content \/ same lines<\/td>Which behavior should survive, or how to combine it.<\/td>Edit the result, remove markers, then git add -- file<\/code>.<\/td><\/tr>
Add \/ add<\/td>Two sides created the same path differently.<\/td>Combine or select the intended file, then stage it.<\/td><\/tr>
Modify \/ delete<\/td>One side deleted a path that the other changed.<\/td>Keep and stage it, or confirm deletion with git rm -- file<\/code>.<\/td><\/tr>
Rename \/ rename or rename \/ delete<\/td>Which final path and content are intended.<\/td>Resolve paths, stage additions and removals, and inspect the full diff.<\/td><\/tr>
Binary file<\/td>Which complete version should be used.<\/td>Select or rebuild a valid file; do not expect line-by-line merging.<\/td><\/tr>
Generated file \/ lockfile<\/td>Which source inputs and tool version should define the output.<\/td>Resolve inputs, regenerate using project tooling, then test.<\/td><\/tr>
Submodule pointer<\/td>Which referenced submodule commit contains the intended work.<\/td>Resolve inside the submodule if needed, then stage its selected commit in the parent repository.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Conflict mechanics and content strategies: [8, 13, 30, 31].<\/p>\n\n\n\n
Ours and theirs depend on the operation<\/strong><\/p>\n\n\n\n
Context<\/strong><\/th>Ours \/ stage 2<\/strong><\/th>Theirs \/ stage 3<\/strong><\/th><\/tr><\/thead>
Merge topic into main<\/td>The checked-out main side.<\/td>The incoming topic side.<\/td><\/tr>
Rebase topic onto main<\/td>The so-far rebased result, starting at main.<\/td>The topic commit currently being replayed.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
During a conflict, the commands below choose a whole file<\/strong>, not just its conflicting hunks. They overwrite the working copy of that conflicted path. Pick one only after reviewing the correct side. [5, 13]<\/p>\n\n\n\n
git restore --ours -- app.txt     # Choose one, not both.\n# OR: git restore --theirs -- app.txt\ngit add -- app.txt<\/code><\/pre>\n\n\n\n
Reuse a resolution, but still review it<\/strong><\/p>\n\n\n\n
git config rerere.enabled true\ngit config rerere.autoupdate false\ngit rerere diff<\/code><\/pre>\n\n\n\n
Rerere records and reuses matching conflict resolutions. Leaving autoupdate false lets you inspect the reused working-tree result before staging it. It saves repeated editing, not the obligation to review and test. [25]<\/p>\n\n\n\n
Avoid preventable conflict noise.<\/strong> Keep formatting-only changes separate from behavior changes. Standardize line endings in .gitattributes<\/code>; where branches genuinely use different normalization rules, a reviewed -Xrenormalize<\/code> merge may help. Do not ignore whitespace blindly in whitespace-sensitive files. [8, 31]<\/p>\n\n\n\n
07. Collaborating without losing someone else’s work<\/h2>\n\n\n\n
Shared topic: preserve the history<\/strong><\/p>\n\n\n\n
Recipe for a local feature\/login tracking a shared remote branch. Fetch first, inspect both sides, then merge the fetched remote tip. A push rejection means the remote may have moved again; inspect it rather than forcing over it. [9, 32]<\/p>\n\n\n\n
git switch feature\/login\ngit fetch origin\ngit log --left-right --oneline HEAD...origin\/feature\/login\ngit merge origin\/feature\/login\n# Review the combined result and run the relevant tests.\ngit push origin HEAD:feature\/login<\/code><\/pre>\n\n\n\n
Private published topic: rewrite only with permission<\/strong><\/p>\n\n\n\n
This recipe first incorporates the remote tip without discarding local commits, records the exact remote value, then rebases. Stop on any failed step. It assumes a clean tree, a topic you are allowed to rewrite, and an unused backup name. [5, 9]<\/p>\n\n\n\n
git switch feature\/login\ngit fetch origin\ngit merge --ff-only origin\/feature\/login\nexpected=$(git rev-parse origin\/feature\/login)\ngit branch backup\/feature-before-rebase\ngit rebase origin\/main\n# Inspect the rewritten diff and rerun the relevant tests.\ngit push \\\n  --force-with-lease=refs\/heads\/feature\/login:\"$expected\" \\\n  origin HEAD:refs\/heads\/feature\/login<\/code><\/pre>\n\n\n\n
Why the explicit lease matters.<\/strong> The push succeeds only if the remote branch still matches the recorded commit. An IDE’s later fetch cannot silently change that saved value. A lease is a concurrency check, not proof that your rewritten content is correct. Never substitute an unrestricted force-push on a shared protected branch. [9]<\/p>\n\n\n\n
Inspect the ancestry relationship precisely<\/strong><\/p>\n\n\n\n
git merge-base --is-ancestor topic main  # Is topic included?\ngit merge-base --is-ancestor main topic  # Is FF possible?\ngit merge-base main topic               # Find a merge base<\/code><\/pre>\n\n\n\n
For --is-ancestor<\/code>, exit 0 means yes, 1 means no, and another non-zero status signals an error. If no common base is visible, check for a shallow clone or wrong remote before concluding the histories are genuinely unrelated. [11]<\/p>\n\n\n\n
Work on a hotfix without disturbing your current checkout<\/strong><\/p>\n\n\n\n
git worktree add -b hotfix\/login ..\/project-hotfix main\n# Work in ..\/project-hotfix; the original working tree stays put.\n# After its work is committed and safe:\ngit worktree remove ..\/project-hotfix<\/code><\/pre>\n\n\n\n
A branch normally cannot be checked out in two linked worktrees at once. Removing a clean worktree is separate from deleting its branch. [19]<\/p>\n\n\n\n
Pull requests, release lines and the final quality gate<\/h3>\n\n\n\n
A pull request \/ merge request<\/strong> is a hosting-service review object, not a native Git commit type. Its final history depends on the repository’s enabled integration method. [20-22]<\/p>\n\n\n\n
Review choice<\/strong><\/th>Result to expect<\/strong><\/th>Important caveat<\/strong><\/th><\/tr><\/thead>
Create a merge commit<\/td>Preserves source commits and adds a merge boundary.<\/td>A linear-history rule may disallow it.<\/td><\/tr>
Squash and merge<\/td>One destination commit for the reviewed change.<\/td>Do not continue stacking new work on the old squashed head without realigning it.<\/td><\/tr>
Rebase and merge<\/td>Separate rewritten commits on the destination without a merge commit.<\/td>GitHub always creates new commit IDs for this option; it is not identical to every local rebase case.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Hosting details above describe GitHub; other products can differ. [20, 21]<\/p>\n\n\n\n
Release and hotfix recipe: Gitflow-style mechanics<\/strong><\/p>\n\n\n\n
Assume main is the stable released line at v1.3.0, develop holds the next release, and you have approval to integrate. These commands show the local mechanics; use equivalent reviewed pull requests when branch protections require them. [24]<\/p>\n\n\n\n
git switch -c hotfix\/1.3.1 v1.3.0\n# Implement, test and commit the focused repair HERE.\ngit switch main\ngit merge --no-ff hotfix\/1.3.1 -m \"Merge hotfix 1.3.1\"\n# Tag only the approved, tested release snapshot.\ngit tag -a v1.3.1 -m \"Release 1.3.1\"\ngit switch develop\ngit merge --no-ff hotfix\/1.3.1 -m \"Bring hotfix to develop\"\n# Push approved branch updates and the tag explicitly.\ngit push origin main develop\ngit push origin v1.3.1<\/code><\/pre>\n\n\n\n
With an active release branch, ensure the repair reaches it too. For an older supported line, cherry-pick the reviewed independent fix rather than importing an entire newer development line. Tags identify snapshots; do not move a published release tag to hide a correction. [7, 24, 28]<\/p>\n\n\n\n
What must be true before integration is declared complete<\/strong><\/p>\n\n\n\n
Confirm the correct target and reviewed diff, no unresolved paths, and a clean or deliberately understood working tree. Run the relevant build, unit, integration and user-interface\/end-to-end tests for the changed behavior. The required CI checks must pass on the intended integration result, not merely on an outdated topic commit. Record the chosen merge method and verify the resulting history.<\/p>\n\n\n\n
A clean merge is only a text\/history result.<\/strong> Two changes can merge without conflict and still break an API contract, database migration, permission check or user flow. Branch protection and tests address different risks; neither replaces review of the actual combined behavior.<\/p>\n\n\n\n
08. Recover according to publication state<\/h2>\n\n\n\n
First run git status<\/code>. Preserve uncommitted work before trying recovery commands. A backup branch protects committed history only; it does not preserve unstaged edits or untracked files. [17, 18, 26]<\/p>\n\n\n\n
Situation<\/strong><\/th>Preferred recovery<\/strong><\/th>Why<\/strong><\/th><\/tr><\/thead>
Ordinary merge still in progress<\/td>git merge --abort<\/code><\/td>Cancels the in-progress merge; a clean starting tree makes recovery more predictable.<\/td><\/tr>
Unpublished completed merge \/ FF<\/td>Move the local target back to a verified pre-operation backup, using reset --keep<\/code> where appropriate.<\/td>No collaborators depend on the discarded branch movement.<\/td><\/tr>
Published merge commit<\/td>git revert -m PARENT MERGE_SHA<\/code><\/td>Adds an explicit inverse commit instead of rewriting shared history.<\/td><\/tr>
Published squash commit<\/td>git revert SQUASH_SHA<\/code><\/td>A squash result is an ordinary one-parent commit.<\/td><\/tr>
Published fast-forward<\/td>Revert the selected ordinary commits in a reviewed, dependency-aware order.<\/td>There is no merge commit to revert as a single merge.<\/td><\/tr>
Lost tip \/ mistaken rebase<\/td>Inspect the reflog and create a rescue branch at the verified old commit.<\/td>Names the recoverable history before further edits.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Prepare before a risky local change<\/strong><\/p>\n\n\n\n
git status --short\ngit branch backup\/pre-integration\n# Only when there is work in progress to preserve:\ngit stash push -u -m \"before integration\"\ngit stash list<\/code><\/pre>\n\n\n\n
Stash -u includes untracked files but not ignored files. Later, inspect the intended entry and use git stash apply<\/code> before dropping it; conflicts can occur while applying it. [26]<\/p>\n\n\n\n
Find and name a lost commit<\/strong><\/p>\n\n\n\n
git reflog --date=iso\ngit show RECOVERED_SHA\ngit branch rescue\/lost-work RECOVERED_SHA<\/code><\/pre>\n\n\n\n
Replace RECOVERED_SHA with the exact commit you inspected. Reflogs are local, expire, and are not a backup of every file edit. Do not assume that HEAD@{1} is always the state you need. [18]<\/p>\n\n\n\n
Reset mode<\/strong><\/th>Index and working-tree consequence<\/strong><\/th><\/tr><\/thead>
--soft COMMIT<\/code><\/td>Moves the branch; leaves index and working files as they are.<\/td><\/tr>
--mixed COMMIT<\/code><\/td>Moves the branch and resets the index; leaves working files.<\/td><\/tr>
--hard COMMIT<\/code><\/td>Overwrites tracked state and can overwrite\/remove obstructing untracked paths. Destructive.<\/td><\/tr>
--keep COMMIT<\/code><\/td>Updates the branch and relevant paths, but refuses when affected local changes would be overwritten.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Reset semantics: [17]. Do not use a hard reset as a routine response to a rejected push or confusing graph.<\/p>\n\n\n\n
R01 | Undo a published merge with revert<\/h3>\n\n\n\n
RECOVERY – PRESERVES HISTORY<\/em><\/p>\n\n\n\n
For a merge that others may already have fetched, create a compensating commit rather than rewriting the shared branch.<\/p>\n\n\n\n
flowchart LR\nsubgraph Before\n  bA[\"A\"] --> bD[\"D\"] --> bM[\"M<br\/>main\"]\n  bA --> bB[\"B\"] --> bC[\"C<br\/>topic\"] --> bM\nend\nsubgraph After\n  aA[\"A\"] --> aD[\"D\"] --> aM[\"M\"] --> aR[\"R<br\/>main\"]\n  aA --> aB[\"B\"] --> aC[\"C<br\/>topic\"] --> aM\nend<\/code><\/pre>\n\n\n\n
Older commits point toward newer commits. Mermaid source: R01<\/a><\/p>\n\n\n\n
lab split\ngit merge topic -m M       # Prepare the BEFORE graph.\ngit show -s --format='%h %p %s' HEAD\n# In THIS lab, parent 1 is previous main (D).\ngit revert -m 1 --no-edit HEAD\ngit diff HEAD~2 HEAD       # Empty in this simple lab.<\/code><\/pre>\n\n\n\n
Result.<\/strong> R reverses the change from D to M. M and the topic ancestry remain in history. Here, with no intervening commits, R has the same tree as D.<\/p>\n\n\n\n
Pros<\/strong><\/th>Cons<\/strong><\/th><\/tr><\/thead>
Safe for shared history; the rollback is explicit and reviewable.<\/td>Can conflict with later edits. Merging the same topic again does not automatically restore the reverted changes.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Watch out.<\/strong> -m 1 selects the parent to keep as the baseline; it is not a commit message. Inspect the parents, do not guess. Reintroduce deliberately with a revert of R or genuinely new changes.<\/p>\n\n\n\n
git merge-base --is-ancestor topic main<\/code><\/pre>\n\n\n\n
Expected:<\/strong> Still exits 0: reverting content does not remove ancestry.<\/p>\n\n\n\n
Reference: [14]<\/p>\n\n\n\n
Troubleshooting and the commands worth remembering<\/h3>\n\n\n\n
Symptom<\/strong><\/th>What to check \/ do next<\/strong><\/th><\/tr><\/thead>
Push rejected: non-fast-forward<\/td>Fetch and compare local versus remote. Merge a shared line, or rebase only where rewriting is allowed. Do not force first.<\/td><\/tr>
Already up to date, but code is missing<\/td>Inspect earlier reverts, squash commits or an ours-strategy merge. Ancestry is not a content guarantee.<\/td><\/tr>
Fast-forward impossible<\/td>Inspect the unique commits on each side. Choose a deliberate merge or authorized rebase; see S05B.<\/td><\/tr>
Local changes would be overwritten<\/td>Commit a coherent change, stash it, or use another worktree. Do not discard edits just to switch branches.<\/td><\/tr>
Branch is not fully merged after squash<\/td>Expected when original source commits are not ancestors of the destination. Verify the delivered patch and dependent work before deletion.<\/td><\/tr>
No merge base \/ unrelated histories<\/td>Verify the remote and whether the clone is shallow. Fetch missing history before using the exceptional unrelated-histories flag.<\/td><\/tr>
Merge still seems unfinished<\/td>Use status and inspect unmerged paths. Stage the resolution and continue the operation that is actually active.<\/td><\/tr>
Rebase keeps stopping<\/td>It replays a series, so later commits may conflict separately. Resolve each; do not skip patches without understanding the loss.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Two easily missed command traps<\/strong><\/p>\n\n\n\n
Review before creating a merge commit:<\/strong> –no-commit alone does not stop a fast-forward. Use –no-ff together with –no-commit when you need an inspectable, not-yet-committed merge result. [4]<\/p>\n\n\n\n
git merge --no-ff --no-commit topic\ngit diff --cached\n# Review and test, then git commit; or git merge --abort.<\/code><\/pre>\n\n\n\n
Abandoning a squash attempt:<\/strong> squash does not set MERGE_HEAD, so merge –abort is not its general undo command. Only after a clean start, with no other edits to keep, the following discards its staged\/working-tree result. [4, 13]<\/p>\n\n\n\n
git restore --source=HEAD --staged --worktree -- .<\/code><\/pre>\n\n\n\n
Danger: the restore command discards edits.<\/strong> It also removes paths added to the index by that squash if they do not exist in HEAD. Never run it over unrelated work you need to keep. Save that work separately first.<\/p>\n\n\n\n
Daily inspection<\/strong><\/p>\n\n\n\n
git status --short\ngit branch -vv\ngit log --graph --oneline --decorate --all\ngit diff --stat main...topic\ngit diff --cached --check\ngit show -s --format=\"%h %p %s\" HEAD<\/code><\/pre>\n\n\n\n
Appendix A. Copyable Mermaid source<\/h2>\n\n\n\n
The complete BEFORE and AFTER Mermaid source appears with each corresponding scenario above. Use this index to jump directly to a diagram. Copy one complete Mermaid block into a Mermaid-capable editor. Labels name the branch pointers; arrows run from older to newer commits. [27]<\/p>\n\n\n\n
S01 | Fast-forward: move the branch pointer<\/a><\/p>\n\n\n\n
S02 | Force a merge commit with –no-ff<\/a><\/p>\n\n\n\n
S03 | Three-way merge: both branches advanced<\/a><\/p>\n\n\n\n
S04 | Three-way merge with a conflict<\/a><\/p>\n\n\n\n
S05A | Already up to date: nothing to merge<\/a><\/p>\n\n\n\n
S05B | Fast-forward-only refuses divergence<\/a><\/p>\n\n\n\n
S06 | Squash merge: one delivery commit<\/a><\/p>\n\n\n\n
S07 | Rebase, then fast-forward<\/a><\/p>\n\n\n\n
S08 | Cherry-pick: bring across one change<\/a><\/p>\n\n\n\n
S09 | Merge main into a feature branch<\/a><\/p>\n\n\n\n
S10 | Octopus: merge several independent topics<\/a><\/p>\n\n\n\n
S11 | Merge histories with no common ancestor<\/a><\/p>\n\n\n\n
S12 | Prefer a side for conflicting hunks: -X<\/a><\/p>\n\n\n\n
S13 | Record ancestry but keep our whole tree<\/a><\/p>\n\n\n\n
S14 | Subtree-aware merge: align directory layouts<\/a><\/p>\n\n\n\n
S15 | Interactive rebase: polish before integration<\/a><\/p>\n\n\n\n
R01 | Undo a published merge with revert<\/a><\/p>\n\n\n\n
Appendix B. Official references and verification<\/h2>\n\n\n\n
Documentation checked on 19 September 2026. Git commands are supported by Git’s manuals and Pro Git; hosting-specific claims use GitHub’s documentation. Workflow guidance additionally uses DORA and the original Gitflow author. All titles below are clickable.<\/p>\n\n\n\n
[1] Pro Git: Branches in a Nutshell<\/strong><\/p>\n\n\n\n
Branch pointers and HEAD<\/a><\/p>\n\n\n\n
[2] Git glossary<\/strong><\/p>\n\n\n\n
Core terms<\/a><\/p>\n\n\n\n
[3] Pro Git: Basic Branching and Merging<\/strong><\/p>\n\n\n\n
Fast-forward and three-way examples<\/a><\/p>\n\n\n\n
[4] git merge<\/strong><\/p>\n\n\n\n
Modes, conflicts and merge state<\/a><\/p>\n\n\n\n
[5] git rebase<\/strong><\/p>\n\n\n\n
Replay, interactive editing and conflict handling<\/a><\/p>\n\n\n\n
[6] git branch<\/strong><\/p>\n\n\n\n
Local refs, tracking and deletion<\/a><\/p>\n\n\n\n
[7] git cherry-pick<\/strong><\/p>\n\n\n\n
Selective replay and provenance<\/a><\/p>\n\n\n\n
[8] Merge strategies<\/strong><\/p>\n\n\n\n
ort, recursive, resolve, octopus, ours and subtree<\/a><\/p>\n\n\n\n
[9] Remote synchronization<\/strong><\/p>\n\n\n\n
git fetch<\/a> | git push and force-with-lease<\/a><\/p>\n\n\n\n
[10] git switch<\/strong><\/p>\n\n\n\n
Branch creation, detached HEAD and orphan starts<\/a><\/p>\n\n\n\n
[11] git merge-base<\/strong><\/p>\n\n\n\n
Common ancestors and ancestry predicates<\/a><\/p>\n\n\n\n
[12] Git revisions<\/strong><\/p>\n\n\n\n
Parent and range notation<\/a><\/p>\n\n\n\n
[13] git restore<\/strong><\/p>\n\n\n\n
Index stages, ours\/theirs and restoring paths<\/a><\/p>\n\n\n\n
[14] git revert<\/strong><\/p>\n\n\n\n
Mainline selection and reverted-merge behavior<\/a><\/p>\n\n\n\n
[15] git pull<\/strong><\/p>\n\n\n\n
Explicit integration modes<\/a><\/p>\n\n\n\n
[16] git diff<\/strong><\/p>\n\n\n\n
Tip comparison, three-dot comparison and checks<\/a><\/p>\n\n\n\n
[17] git reset<\/strong><\/p>\n\n\n\n
Reset modes and recovery consequences<\/a><\/p>\n\n\n\n
[18] git reflog<\/strong><\/p>\n\n\n\n
Local reference history and expiration<\/a><\/p>\n\n\n\n
[19] git worktree<\/strong><\/p>\n\n\n\n
Linked working trees<\/a><\/p>\n\n\n\n
[20] GitHub: Protected branches<\/strong><\/p>\n\n\n\n
Review and status-check restrictions<\/a><\/p>\n\n\n\n
[21] GitHub: Pull request merges<\/strong><\/p>\n\n\n\n
Merge, squash and rebase behavior<\/a><\/p>\n\n\n\n
[22] GitHub flow<\/strong><\/p>\n\n\n\n
Branch, review and integration lifecycle<\/a><\/p>\n\n\n\n
[23] DORA: Trunk-based development<\/strong><\/p>\n\n\n\n
Short-lived work and continuous integration<\/a><\/p>\n\n\n\n
[24] Vincent Driessen: A successful Git branching model<\/strong><\/p>\n\n\n\n
Gitflow and its later applicability note<\/a><\/p>\n\n\n\n
[25] git rerere<\/strong><\/p>\n\n\n\n
Recorded conflict resolution reuse<\/a><\/p>\n\n\n\n
[26] git stash<\/strong><\/p>\n\n\n\n
Saving and restoring work in progress<\/a><\/p>\n\n\n\n
[27] Mermaid: Flowcharts<\/strong><\/p>\n\n\n\n
Nodes, links and subgraphs<\/a><\/p>\n\n\n\n
[28] git tag<\/strong><\/p>\n\n\n\n
Annotated tags and release references<\/a><\/p>\n\n\n\n
[29] Pro Git: Rebasing<\/strong><\/p>\n\n\n\n
Replayed commits and publication caution<\/a><\/p>\n\n\n\n
[30] Pro Git: Advanced Merging<\/strong><\/p>\n\n\n\n
Conflict inspection and exceptional merges<\/a><\/p>\n\n\n\n
[31] Git attributes<\/strong><\/p>\n\n\n\n
Normalization and content merge behavior<\/a><\/p>\n\n\n\n
[32] Pro Git: Remote Branches<\/strong><\/p>\n\n\n\n
Tracking refs and synchronization<\/a><\/p>\n\n\n\n
Executable verification<\/strong><\/p>\n\n\n\n
The 17 scenario and recovery recipes were executed in isolated disposable repositories with Git 2.47.3<\/strong>. Checks covered branch tips, parent counts, intended refusals, resolved file contents, squash and cherry-pick ancestry, rewritten commits, three-parent octopus history, separate roots, both -X variants, unchanged ours-strategy trees, subtree paths, and revert behavior. Interactive rebase was checked with the specified pick\/fixup todo list.<\/p>\n\n\n\n
The lab tests validate Git mechanics, not application correctness. Run project-specific tests and honor repository policy before integrating real work. Statements about newer Git behavior, such as the recursive alias beginning in 2.50, come from the current official manuals.<\/p>\n\n\n\n
One durable habit.<\/strong> Before every integration, know the target, the source, the intended history shape, and the recovery path. After it, verify both the graph and the behavior.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
PRACTICAL TECHNICAL HANDBOOK \/ 19 SEPTEMBER 2026 Git Branching & Merging Branch types, integration choices, conflicts and safe recovery Understand what Git changes, choose the right method,… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1165","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1165","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1165"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1165\/revisions"}],"predecessor-version":[{"id":1186,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1165\/revisions\/1186"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1165"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}