Git Branch and Merge

A Git branch is a named, movable reference to a commit. It lets a line of work advance while another branch stays at its current commit. Creating a branch does not copy the whole project into another folder. HEAD normally identifies the checked-out branch, and a new commit advances that branch.

A merge combines development histories. If the target branch can simply advance to a descendant commit, Git can perform a fast-forward without creating a merge commit. When histories have diverged, a normal successful merge can record the combined result in a commit with both histories as parents. Team options can choose different recording policies.

When Git cannot combine changes automatically, it leaves a conflict for a person to resolve. In a normal merge, text markers commonly separate the current branch’s content from the incoming content. Removing the markers is only the text-editing step. Decide what the combined code should mean, test it, stage the resolution, and complete the merge. A conflict-free merge can still introduce a semantic error, such as combining a renamed field with a query that still expects the old name.

A remote-tracking reference such as origin/main records the remote state last fetched locally; it is not a live view. Fetch updates that information without automatically merging it into your work. Start a merge with a clean working tree so aborting does not have to disentangle pre-existing edits. A branch named main is a convention, not evidence that its content has been reviewed or deployed.

References

• Pro Git: Basic Branching and Merging

Practice these ideas in Linux, the Shell, and Git for Data Work.