2. Workflow - FHS-Robotics/FRC-VSCode-Team5866 GitHub Wiki

The workflow for this repository will go as follows:

  1. Create an issue for the code that needs to be added. This issue should contain a description of the task and what has to be completed in order for it to be considered done.
  2. Someone will take on the issue. That person will comment something like "I'm on it!"
  3. That person will, in VS Code, create a new branch (or check out a current one that corresponds with that issue).
  4. Make sure that when you make a branch or are editing one that you check out that branch in VS Code. In order to check out a branch that's on github that you don't have on your local machine, go to the VS console and run "Git: Checkout from" and select the online branch.
  5. Once you are done editing and making changes or additions, create a commit with a description of the code that you added or changed. This commit will be part of the repository's history for everyone to see your purpose for what you did.
  6. Push your code from your local branch to the branch on GitHub.
  7. Make sure that as you reach a milestone of working code or create a new file and are done developing for that current session, push your changes to the online branch. This way, when other people are also making changes to the code in development, they are in sync with what you are doing. Once the code that you've developed for that branch is fully working and without bugs, and only then, can you sync the development branch with the master branch.
  8. Create a pull request to merge your code into the master repository. Write again a description or some request to add your code into our mainstream project.
  9. Others will review your request and if everyone agrees, a code owner will merge your changes into the master branch.
  10. If not, don't worry! Just take the others feedback and either go back and work on the code again or maybe someone else will checkout your branch before we merge.
  11. When that section of the code is finished and out of development, we can delete the branch. Do not delete the branch unless the group has talked about it first. For example, if the driving code is polished, then we can delete the "DriveBase" branch. Until then, keep it up so that it can be developed. If later we decide to make a change to the code that's substantial, we can recreate the branch. By deleting branches from already-developed features, the process stays clean.