Skip to content
This repository has been archived by the owner on May 18, 2023. It is now read-only.

git Workflow

Jump to bottom
Nathan Baltzell edited this page Mar 15, 2018 · 24 revisions

One of the main advantages of git (vs svn/cvs) is branches/forks. Some of the advantages of github are "issues" and their "assignees", pull request "reviewers". All this benefits situations with many simultaneous developers and fast and tractable development.

branches

Branches/forks are easiest if used temporarily, for smaller projects with well-defined goals. Your own neverending branch for all your development, spanning multiple topics, can be a headache if it gets too far behind its mother branch.

git commands

  • download the repository:
  • make a new branch named myBranch:
    • off of master:
      • git checkout -b myBranch
    • off of development:
      • git checkout development
      • git checkout -b myBranch development
  • commit changes in your local repository:
    • git commit -m 'MyEngine: code cleanup' path/to/cleanedup/files
  • push local changes to remote repository:
    • git push origin myBranch

commits

All commits should have useful messages

  • e.g. just 'minor' or 'updated [my detector]' are not very useful
  • concisely state what was really changed
  • can/should reference the packake/dir that was upgraded
  • note that you can also use multiple commit messages (-m) on one commit

github "issues"

  • anyone can make an "issue", and "assign" it to someone
  • one model is that each issue is addressed on one unique branch of the same name
  • pull request's comments can say whether issue is resolved
    • issue should be closed/amended when pull request is accepted

Workflows

No direct commits to the main branch, only pull requests, not even "experts". No pull requests should be accepted by the requester, not even "experts". Pull requests can/should also tag a reviewer. All this serves at least to announce the changes, ideally to put some more eyes on it before they happen, hopefully to make development more transparent to all and easier to catch bugs before the propagate.

A

Here master is the main branch for development. This is more similar to our current workflow than B below.

  1. make a new branch off of master, or fork repo and work on master
  2. make changes, complete task, test changes (including running some/all builtin validation tests)
  3. submit pull request via github website
  4. request accepted/amended/commented/rejected by someone else
  5. if accepted and merged into main branch, probably just delete your branch

B

Here development is the main branch for development and would be used like master in A above, i.e. the only modification to the steps is in #1:

  1. make a new branch off of development, or fork repo and work on development

Testing and development is done on the development branch, fully vetted before merging to master:

  • no one ever submits a pull request or commit on master
  • development branch is merged into master by the expert, e.g. for a new release
  • all releases are done on master, pre-releases can be done on development
Clone this wiki locally