Skip to content

Latest commit

 

History

History
26 lines (19 loc) · 1.82 KB

git.md

File metadata and controls

26 lines (19 loc) · 1.82 KB
Raw

Git

Branching

Follow the git branching model

  • master is for releases
  • develop should generally not be worked on directly unless they are non-functional or trivial changes and apply project-wide
    • develop acts as the staging branch for CI and should be as stable as master
  • Create separate branches for each feature and isolate set of fixes
  • Each feature should branch off develop unless the branch depends on an existing unmerged feature/bug-fix branch

Merging

  • To prevent noise in the develop and master branches, feature/bug-fix merges will be squashed unless there is a good reason to keep the history, in which case the branch owner must rebase against develop
    • Read about the difference here.
  • The maintainer/release manager of the project is responsible for reviewing the feature/bug-fix branch and merging it into develop, then ultimately master when a release occurs

Commit Messages

  • Commit messages should be present tense since the commit message is a description of what has happened (in that commit), not what had happened
    • e.g. "Fix missing local reference to foo", not "Fixed" or "Fixing"
  • If a commit is intended to be visible in the history, it must have a meaningful commit message
    • This should not require others to look at the code to generally understand what changed
  • For bad commits that require a subsequent "fixed", "fixing", "whoops" commit message use git commit --amend to ammend the previous commit
    • On a side note, if you already pushed the commit you need to ammend, you can do git push --force for your branch to force overwriting thte commit on the server. Be aware of the impact of this if other developers are working on the same branch.