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 branching commands

  • download the repository:
  • make your new branch:
    • 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
  • go to your branch/fork in web browser and do a pull request
    • assign a reviewer

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 they happen.

A

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

  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 (use github website for commenting/amending/rejecting pull requests)
  5. delete branch

B

Here development is the main branch for development and testing and would be used like master in A above, i.e. Step 1 would be to branch off of development, or fork repo and work on master

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