Skip to content
academia.sh
tr
Log in

Course Intermediate

Branching and Collaboration

By the end of this course

Start course

01

Branches

The branch as pointer and how cheap branching is, adapting the workspace through branch creation and switching, a readable naming convention within a team, and how detached HEAD arises and how to get out of it.

  1. 01 The Concept of a Branch A branch is a pointer: in a twelve-commit setup, opening three branches writes zero new commits and 123 bytes of reference, and while the copy model copies twelve thousand files for the same tree at four thousand files, the pointer model's cost stays constant.
  2. 02 Branch Creation and Switching Opening a branch and switching to it are separate operations: the switch only rewrites files that differ between the two branches, and of the twelve remaining-change cases, 3 move along, 5 block the switch, 4 are left behind; none is silently lost.
  3. 03 Branch Naming A branch naming convention adds to history's first question what the branch record alone cannot: of the eight combinations of two integration formats and four naming conventions, the group is actually readable in only 3, because keeping a record and having a readable name are two separate conditions.
  4. 04 Detached HEAD State When two commits made on a detached HEAD are reachable from no reference, history drops from 15 records to 13 and answers 4 of the six questions instead of 5; the real cost is that all three counting queries are answered incompletely, and history does not report it.

02

Merging and Rebasing

The difference between fast-forward and the merge commit, conflict markers and verifying a resolution, the cost of linearizing history, moving a single commit to another branch, and a criterion-based choice among four integration formats.

  1. 01 Fast-Forward and Merge Commit Merging two branches writes either nothing to history or a commit with two parents; a twelve-commit development grows to fifteen and answers five of six questions as a merge commit, or stays at twelve and answers three as a fast-forward.
  2. 02 Conflict Resolution When the tool cannot merge two sides, it writes conflict markers to the file; the resolution is given by hand, but none of the four integration formats records the chosen side, and the resolution's rationale stands nowhere unless it is written into the commit message.
  3. 03 Rebase The format that rewrites a branch's commits onto a new base leaves twelve commits as twelve and answers three of six questions; the total matches fast-forward but the loss does not — one preserves branch integrity, the other true order.
  4. 04 Cherry-Pick Copying a single commit to another branch leaves the same change in history in two places under two separate IDs; the file trail question still says yes, but the commit count it counts exceeds the count of separate changes, and the isolation question drops when a buggy commit is copied.
  5. 05 Merge Strategies Four integration formats bring the same twelve-commit development into main and leave 15, 12, 3, and 12 commits in history; the number of questions they answer is 5, 3, 2, and 3, and squash, the cleanest history, makes all twelve commits unreadable individually.
  6. 06 Branch Strategies How long a branch lives determines what gets written to history: the same twelve commits leave 12 with no branch opened, 15 under a pattern that returns every four commits, and 24 under a pattern that returns every commit — and once the divergence window closes, a merge conflict never arises at all.

03

Remote Repositories and the Contribution Flow

Managing multiple remotes, the distinction between fetch, pull, and push, forking and cloning as two separate contribution models, the pull request cycle, and patch-based contribution.

  1. 01 Defining a Remote Repository Defining a remote binds a name to an address and does not touch history; three copies carry 5, 10, and 15 commits respectively and answer 4, 5, 5 questions, and after two definitions the local copy still stays at 5 commits and 4 questions.
  2. 02 Fetch, Pull, and Push The three synchronization operations touch local history at different points: fetch leaves the local branch at 5 commits and raises local objects to 15, pull carries the branch to 16 commits and 5 questions, push changes the other side's branch from 10 to 16.
  3. 03 Forking and Cloning In the two contribution models, the question the upstream repository can answer depends on the integration format: 15 commits answer 5, 12 commits answer 3, 3 commits answer 2, and because the fork repository carries 12 commits and answers 5 questions, three questions stand only in a copy the upstream repository does not own.
  4. 04 Pull Request Flow The integration format the flow chooses leaves history 5, 3, 2, and 3 questions; of the 11 decisions taken across three requests, 4 are written to a commit message, 7 never enter history in any format, and under squash even the written ones stop being separately readable.
  5. 05 Patch-Based Contribution A patch is a text file and encodes the change, not the graph: push with history leaves 5 questions in 15 commits, the mail-formatted series 4 in 12, the plain diff series 3 in 12, the single plain diff 1 in 1 commit, and under the plain diff, author-preserved commits are 0.

Start typing to search.

↑↓ ↵ Esc navigate · open · close