Git Best Practices - BKJackson/BKJackson_Wiki GitHub Wiki

Git Repo Structures

Only two permanent branches:

  1. Master (=Production)

    • use release tags: v1.0, v2.0, etc.

  2. Development

  • always pulled into master

For new customers, use Fork

Git Best Practices

How To Manage A Shared Codebase - 2020
Understanding the GitHub flow - Github guide
5 Git Workflow Best Practices You've Got To Use [2018]
How Git best practices saved me hours of rework
Commit Often, Perfect Later, Publish Once: Git Best Practices
Version control for fun and profit: the tool you didn't know you needed. From personal workflows to open collaboration - Fernando Perez
Pull Request Workflow (Video)
A Lighter Pull Request Workflow - Built for speed

Git Workflows for Jupyter Notebooks

Earth Analytics Bootcamp - Git/Github.com Workflow For Version Control
Earth Analytics Bootcamp - Git/Github.com For Collaboration

Five Stages of Git

Scenarios of increasing sophistication and complexity...

  1. Local, single-user, linear workflow
  2. Single local user, branching
  3. Using remotes as a single user
  4. Remotes for collaborating in a small team
  5. Full-contact github: distributed collaboration with large teams

Exploring Version History with Git

Software Carpentry - Exploring Git History - Explains HEAD and how to use it, restoring old versions of files, etc.

General (non-Git) Development to Production Best Practices

The Twelve-Factor App - Main idea: Keep development, staging, and production as similar as possible
Build, release, run - Strictly separate build and run stages
A codebase is transformed into a (non-development) deploy through three stages:

  • The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors dependencies and compiles binaries and assets.
  • The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.
  • The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s processes against a selected release.