GitHub flow

As explained in GitHub Actions in Action: Continuous integration and delivery for DevOps

GitHub Flow is a lightweight branching workflow in which changes are developed on branches, reviewed through pull requests, merged into the main branch, and deployed.

GitHub Flow is a lightweight branching workflow for delivering software: develop changes on a feature branch, review them through a pull request, merge into main, and deploy to production. section 8.3.1

Apply the workflow in this sequence:

• Create a branch such as feature/name-of-feature and commit the change there. section 8.3.1
• Run fast-feedback checks on the feature branch, such as compiling the committed sources. section 8.7
• Open a pull request when the feature is ready, then solicit feedback, complete peer review, and obtain approval. section 8.3.1
• Protect main from direct commits so every change passes through a pull request and an additional person reviews the production-bound change. section 8.3.1
• Merge approved changes into main, create container images, publish them to GitHub's container registry, and trigger a versioned release that can start continuous delivery. section 8.7

A staged workflow

A feature branch first receives compilation feedback. Its pull request then triggers testing and security quality checks. After approval and merge, image creation and registry publication produce a versioned release for the next deployment phase. section 8.7

Figure 8.4 The GitHub Flow branching strategy

Use the branching-strategy diagram to follow the path from feature branch through pull request, merge, and deployment. section 8.3.1

How GitHub Actions in Action: Continuous integration and delivery for DevOps covers it

How deep it goes

Explains branch, review, protection, merge, and trigger stages, while deferring detailed action-workflow implementation to surrounding workflows.

Examples

Uses feature/name-of-feature branches, pull requests, compilation checks, security checks, container registries, and versioned releases.

What it assumes

Assumes familiarity with Git repositories, branches, commits, pull requests, and software delivery workflows.

What you can do after

Operate a reviewed branching workflow that produces deployable main-branch changes and staged release artifacts.

How it connects

Connects branching strategy with continuous integration, pull requests, code review, security testing, container images, releases, and continuous delivery.

liveBookmanning.com

Read GitHub Actions in Action: Continuous integration and delivery for DevOps on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Think Like a CTOA simplified Git branching model centered on a main branch and short-lived feature branches that are reviewed, tested, and merged for deployment.

Compare how 2 books explain GitHub flow →

Related concepts

• branchuses · A branch is an independently evolving line of development in a version-control repository, typically represented by a reference to a sequence of changes or commits.
• versioning patternkind of · A prescribed arrangement of branches, integrations, releases, and related version-control practices.
• pull requestuses · A pull request is a version-control proposal to integrate changes from one branch or repository into another, typically supporting review and discussion before merging.
• trunk-based developmentalternative to · Trunk-based development is a software workflow in which developers frequently integrate small changes into a shared mainline, typically using short-lived or no feature branches.
• code reviewuses · Code review is the systematic examination of source code or proposed changes to identify problems and assess or improve quality.

This explainer was generated by Manning's knowledge graph from the text of GitHub Actions in Action: Continuous integration and delivery for DevOps. The section links point to the parts of the book it draws on.