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:
Beginning an Iteration
Performing Tasks
✅ 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
Contributing Code to the Project
✅ Review and Merge the Pull Request, Possibly Making Corrections along the Way
Details about the various steps of the workflow follow.
At the start of each iteration, your team 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.
In addition to creating a GitHub milestone, your team must also create task plans for each team member to perform at the start of each iteration. The task plans must be entered into the mX-tasks spreadsheet (where X is the number of the milestone the plans are for) as per this instructional video:
Here are some criteria for the task plans:
At Least 10 Hours of Work per Team Member per Iteration: Each team member should plan tasks that total at least 10 hours of work for each iteration.
More Than 2 Tasks per Team Member per Iteration: Each team member should have at least two or more tasks assigned to them.
Everybody Codes: For each development iteration, each and every team member must take on substantial coding tasks (although it’s possible to have some tasks that don’t involve coding).
No Shared Task Assignments: Do not assign a task to more than one team member. Although team members are encouraged to collaborate, the responsibility for completing a particular task must lie with one and only one team member. Teammates who assist on a task can be credited in the task reflection.
Only (Sub)Tasks That Yield Project Artifacts: Generally, you should specify only tasks and subtasks that yield project artifacts. For example, you should not have tasks/subtask that involve only learning about something, and
No Learning-Only Tasks: It is assumed that team members will need to put effort into learning new technologies during the project. However, such effort should not be specified as a task. Generally, only specify tasks that yield project artifacts.
No Communication Tasks: It is assumed that team members will put effort into team communication and coordination each iteration. These types of effort should not be counted as tasks. Generally, only specify tasks that yield project artifacts.
For each 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
The first time you push the topic branch, use this command to set the upstream branch (assuming that the topic branch is named my-topic-branch):
git push -u origin my-topic-branch
After you run the above push command once, you can thereafter use this shorter form of push:
git push
And, you can use this shorter form of pull:
git pull
While on the topic branch, make changes, commit them locally, and push them to GitHub. All changes made this way should be fully contained in the topic branch.
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.
Once you successfully merged a pull request, you must fill out the reflection portion of the appropriate sheet in the mX-tasks spreadsheet. This instructional video shows how:
Scored out of 20 possible points.
Half of the points (up to 10) will be awarded based upon the percentage of task plans that are free from the following defects:
The other half of points (up to 10) will be awarded based upon the percentage of task reflections that are free from the following defects: