Introduction

  • A Git branch is an independent line of development; the default is conventionally called main (but all branches are equal and the main branch can be renamed).
  • Branches help you manage change, collaborate better, and avoid messy mistakes on main.
  • Feature branches let you develop and test code without affecting the main branch and support collaborative and parallel development.
  • Fast-forward merges are used when the main branch has not changed since the feature branch was created, resulting in a linear history.
  • 3-way merges occur when both branches have diverged; Git creates a merge commit to preserve both histories.
  • Rebasing replays feature branch commits on top of the main branch for a cleaner, linear history—but it rewrites history and should be used with care.
  • Squash and merge compresses all changes from a feature branch into a single commit, simplifying history.
  • Understanding different merge strategies and when to use them is crucial for maintaining clean and manageable project histories.

Example Code

  • Using Git branches helps us keep different strands of development separated, so development in one strand doesn’t impact and confuse development in the others
  • Branches created to work specifically on a particular code feature are called feature branches
  • GitHub allows us to capture, describe and organise issues with our code to work on later

Feature Branch Workflow

  • A branch is one version of your project that can contain its own set of commits
  • Feature branches enable us to develop / explore / test new code features without affecting the stable main code
  • Use git branch to create a new branch in Git
  • Use git switch to change to and use another branch
  • Add an issue number, e.g. #1 to a Git commit message so GitHub registers those commits under that issue
  • Use git push --set-upstream origin branch-name to push the commits on a new branch to a GitHub repository

Creating a Pull Request

  • Always test code before you push changes to a remote repository
  • Pull requests give us the opportunity to properly consider and review logical sets of changes to our codebase before they are merged
  • GitHub gives us powerful tools to create and manage pull requests
  • Where possible, keep Git branches short lived and merge them as soon as is convenient, to avoid increasing disparities between the feature branch and main branch

Merging a Pull Request

  • Choose the branch merging method that is right for the situation
  • If you use a rebasing merging strategy, remember the Golden Rule: only rebase with a local branch, never a public (shared) branch you suspect is being used by others
  • Commits related to a particular issue (and referred to in its commit message) are viewable under that issue

Resolving Merge Conflicts

  • GitHub’s interface helps us identify where conflicts exist for a pull request
  • Resolving merge conflicts on a per-conflict basis is achievable from within GitHub