liveBook · Manning

Branch

As explained in Think Like a CTO

A named line of development in a version-control repository that can diverge from and later be integrated with another line.

A branch is a named line of development that lets work diverge, remain organized, and later integrate with another line. Effective branch structures balance separation against management overhead. section 9.3

Choose branch responsibilities and rules according to team and enterprise needs:

  • Use too few branches and commits become harder to segregate and manage; use too many and branch overhead becomes burdensome. section 9.3
  • Define feature-branch naming, ticket-system integration, branch lifetime, granularity, release cycle, and reporting conventions. section 9.3

Two workable patterns

Gitflow uses protected master and develop branches: feature branches start from develop, receive review, and merge back; releases merge develop into master. GitHub flow simplifies this to one master branch, with reviewed and tested feature branches merged into it for deployment. section 9.3

How Think Like a CTO covers it

How deep it goes
Explains branch-count trade-offs and workflow policies, but stops short of implementation details.
Examples
Compares Gitflow’s master/develop structure with GitHub flow’s single-master structure and feature branches.
What you can do after
Operate/configure branch workflows by selecting branch structure, naming, lifetime, review, integration, and release rules.
How it connects
Connects feature branches with version control, code review, merging, release cycles, and ticket-system integration.

Also explained in

Compare how 6 books explain branch →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a CTO. The section links point to the parts of the book it draws on.