Document pushing/branching policies #3

Open
opened 2016-01-29 20:53:39 +00:00 by afitz0 · 0 comments
afitz0 commented 2016-01-29 20:53:39 +00:00 (Migrated from github.com)

Any rules or policies you decide for committing code to this repository need to be documented, written down, and visible (e.g., in the README). A few examples (i.e., things we talked about in last night's meeting) are:

  • The master branch always works and is always what we pull from to use on the Robot.
  • Fiona, jointly with Aaron, is the gatekeeper for what is accepted into master. If your name isn't Fiona, you should be pushing either to a fork or to a non-master branch.
  • When master is at a solid point (e.g., "Connects to robot successfully" or "Connects to robot and spins motor A for 1 second") a tag/release is cut so that it's quick and easy to rollback to this points.
  • Whenever you're making a commit, double check what branch you're committing to.
  • At the end of every day, all code should be committed and pushed. If that day's work has not been approved for master, it's pushed to a non-master branch or a fork.
  • If you have code that you believe is ready to be in master, submit a pull request. This can be done either from a personal fork or a branch on the main repo.
    • You, as the requester, are responsible for ensuring that you've sync'd with master and have no merger conflicts at the time of the request.
Any rules or policies you decide for committing code to this repository need to be documented, written down, and visible (e.g., in the README). A few examples (i.e., things we talked about in last night's meeting) are: - The master branch **always** works and is **always** what we pull from to use on the Robot. - Fiona, jointly with Aaron, is the gatekeeper for what is accepted into master. If your name isn't Fiona, you should be pushing either to a fork or to a non-master branch. - When master is at a solid point (e.g., "Connects to robot successfully" or "Connects to robot and spins motor A for 1 second") a tag/release is cut so that it's quick and easy to rollback to this points. - Whenever you're making a commit, double check what branch you're committing to. - At the end of every day, all code should be committed and pushed. If that day's work has not been approved for master, it's pushed to a non-master branch or a fork. - If you have code that you believe is ready to be in master, submit a pull request. This can be done either from a personal fork or a branch on the main repo. - _You_, as the requester, are responsible for ensuring that you've sync'd with master and have no merger conflicts at the time of the request.
Commenting is not possible because the repository is archived.
No description provided.