The Philosophy of Git and GitHub

Git’s design is a great example of the Unix design philosophy: many small programs. Though originally designed as a toolkit, it instead became program comprised of many small components.

Git’s objectives are to support distributed/offline productivity, speed and frictionless context switching.

Git helps the user retain accountability and authorship for each action taken, maintains the integrity of the project and improves the overall communication between collaborators (e.g. it’s much more than a way to stash code safely).

The design philosophy is reflected in the common usage philosophy:

  • Commit early, commit often
  • Each commit represents one idea or one whole change (easier to read or revert)
  • Each branch represents one feature (or topic) (easier to read or merge)
  • Your local working directory, index and local repo are scratch pads.

GitHub also has it’s own philosophy called GitHub Flow:

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
  • Commit to that branch locally and regularly push your work to the same named branch on the server
  • When you need feedback or help, or you think the branch is ready for merging, open a pull request
  • After someone else has reviewed and signed off on the feature, you can merge it into master
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately

For the teams I work with, we follow a combination of the two.

  • Anything in origin master is deployable.
  • Create a descriptively named branch off of master for new feature dev
  • Commit early and often to new branch locally
  • Ensure that each commit represents one idea or complete change.
  • Push your new branch work to the same named branch on origin frequently.
  • Code reviews are conducted against new branches before merging with master.
  • Named branches are merged with master and tested locally before being pushed to origin master.
  • Deploy origin master to stage for a smoke and regression test.
  • Deploy origin master to prod if testing does not reveal any issues.

1 Comment on "The Philosophy of Git and GitHub"

Comments are closed.

%d bloggers like this: