In this document, I will explain the workflow to follow for doing work on the team project. The workflow mostly follows the popular GitHub Flow workflow. Here is a summary of the workflow:
✅ Assign Project Coordinator and QA Czar Roles
✅ Create a Topic Branch for Your Task
✅ Push Work Done on Your Topic Branch to the GitHub Repo
✅ Merge Changes to the main Branch into Your Topic Branch
✅ Review and Merge the Pull Request, Possibly Making Corrections along the Way
✅ Create a Demo Video and Report
Details about the various steps of the workflow follow.
At the start of each iteration, your team must perform the following tasks.
The team must assign one member to the Project Coordinator role and two members to the QA Czar role. The team should assign these roles democratically, since the roles serve key functions on the team. See this document for lists of the responsibilities associated with each role. Note that the Project Coordinator and QA Czars receive A&B points for performing their responsibilities.
Your team’s Project Coordinator (or their designee) must create a milestone for the iteration in GitHub. Here is a GitHub Help article on milestones. You need to do this only once per milestone in GitHub. Each GitHub milestone is used to group issues and pull requests that contribute to a particular milestone. Name the Github milestone Milestone M1 or Milestone M2, as appropriate.
Your team must must plan coding tasks for each team member to perform during the iteration. Task plans must follow these instructions.
For each coding task you work on, you will perform your work in a topic branch.
From the main branch, you might use this command to create a my-topic-branch topic branch and to switch to that branch:
git switch -c my-topic-branch
This git switch -c command will create a topic branch in your local repository.
To set up a tracking branch in the GitHub repo that corresponds with this local branch, run this command:
git push -u origin my-topic-branch
After you run the above git push -u command once, you can begin working on your task, committing and pushing your work as you go.
While on the topic branch, make changes, commit them locally (i.e., using git add and git commit), and push them to GitHub. All changes made this way should be fully contained within the topic branch.
Since you set up tracking with the remote branch, you can use this shorter form of git push to push changes to the GitHub repo:
git push
main Branch into Your Topic BranchIf other teammates merge changes into the main branch while you are working on your topic branch, you will need merge those changes into your topic branch before you’re done. From your topic branch, you can use this command to merge the remote main branch into your topic branch (although you may need to manually resolve merge conflicts after the command):
git pull origin main
Once you complete a task, the next thing to do is merge your work into your team’s main branch. To do so, you must submit the work via a GitHub pull request. Then, one of your team’s QA Czars must review the pull request. Once the QA Czar finds the pull request acceptable, they must accept the pull request and merge it into the main branch.
Create the pull request as follows:
Title: The title must concisely express what is included in the pull request. Often the title entered into the task plan will be appropriate here, but not always (e.g., if the task was only partially completed).
Reviewers: You must set the reviewers to your team’s QA Czars for the iteration, that is, the ones who will review pull requests.
Milestone: The milestone must be set to the current GitHub milestone for the iteration.
All other pull request fields may be left blank.
It is the job of one of your team’s QA Czars to review your pull request. They must test it to make sure that it works and confirm that it can be fast-forward merged with the main branch. They must post comments or change requests if they find issues. To test the code, the QA Czar can pull the branch to their local repository and check it out using the following commands (assuming that the topic branch is named my-topic-branch).
First, the QA Czar must download the latest state of the remote repo, like this:
git fetch
Then, the QA Czar must switch to the my-topic-branch branch, like this:
git switch my-topic-branch
If changes are needed, the author of the topic branch must make them to their working copy and push them to GitHub (all still in that topic branch). The pull request will be automatically updated to reflect the changes. The author will probably also want to reply to the comment in the pull request, so the QA Czar is notified of what’s happened.
Once the QA Czar approves the change, they should also merge it into the main branch.
If other pull requests are merged into the main branch before yours is, you will need to merge those changes into your topic branch before your pull request can be merged (see the Merge Changes to the main Branch into Your Topic Branch section above).
Upon completion of a task, you must complete a task reflection that describes how the task went. Task reflections must follow these instructions.
At the end of each development iteration, once all team members’ tasks have been completed and their pull requests have been merged into the main branch, the final steps to complete the iteration must be performed.
Your team’s Project Coordinator (or their designee) must create a GitHub release of the code in the main branch for the milestone. The release must follow these instructions.
Your team must create a video demo and accompanying report. Your video and report must follow these instructions. Note that team members who contribute to the video should earn A&B points.