Assignment 1: Using Git & Github to Get Ready for Collaborative TypeScript Development¶
Possible Points | Due Date |
---|---|
50 pts | Tuesday August 27th - 11:59pm |
Overview¶
After this assignment, you should be able to use Git and GitHub for your teamwork in this course and other projects. You should know about the GitFlow workflow and how to collaborate with other developers in their projects. You will learn about working with Git and GitHub by converting a file from JavaScript to TypeScript - a migration that you will perform again during the Software Development Project.
Prerequisites¶
- You have a GitHub account
- You have Git installed
- You have TypeScript installed
- You know Git Basics
Authenticating GitHub on your local Machine
Github now requires two-factor authentication and token-based access to clone repositories using https
. Check out this article for more information: https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls
Part 1a: Forking a Repo¶
- Fork this repository
- Under the General tab in Settings, check the "Issues" checkbox in the "Features" section to enable the issues pane for your repository
- Clone the repository onto your local machine
Part 1b: Run a GitHub Action Workflow¶
- On Github, click the Actions tab, enable the workflows and select the “Lint and Test” workflow
- Click on the "Run workflow" dropdown, then the "Run workflow" button (leave Branch to be
main
). This runs the GitHub workflow that runs the linter and tests on the project
Our GH actions pipeline suggests that the main branch is broken! Let’s walk through the process to fix these errors.
Merging to main
In practice, you should not merge a branch into the main branch that could cause main to fail. This way, we can ensure that all the code on main is our most recent working product
Part 2: Setting up a Kanban Board and Creating Issues¶
- Click through the build output and take a look at why eslint is failing. Take note of the names of each file - you should use these when naming your issues!
- Create a project board by clicking on the Projects tab, and then "New project" under the "Link a project" drop down button. Use the "Board" template.
- Under the Issues tab, create an issue for for correctly translating each typescript file that fails the eslint workflow
- Assign yourselves to both issues, and add the issues to the project Kanban board you just created using the "Projects" option (two fields below "Assignees")
- Make sure that your Kanban board is publicly accessible and is associated with your forked project repo! The board will need to be publicly accessible for us properly grade your assignment. Be sure to double check its visibility is set to public!
- Note in the future you can sahre Kanban/Project board with your teammates or make it public so they have access to it.
Part 3: Branching, Committing, and Pushing¶
- In your local machine, create a new branch with a relevant name to the issue you are addressing (e.g. "fix-header-sizing-issue", "fix-multiple-dialog-bug", "add-sorting-feature"). For this assignment, be sure to create two branches, one for each of the issues that you need to fix.
- Fix the issue that you were assigned to, then add and commit the changes
- Commits should start with a verb, and what it does to the codebase (e.g. "Remove faulty condition from getCustomerDetails", "Fix failing CompositeTestCase", "Fix issue #21" )
- Push the branch to remote
Part 4: Writing Pull Requests¶
- On GitHub, create a pull request to merge the changes from the branch you have just pushed to the main branch
- Make sure it is to the main of your own forked repository! By default, Github selects the original repository instead of your own forked repository.
- Name your pull request appropriately
- In the description, describe what changes has been made to address the issue, and how has the changes been tested
- Notice that the GitHub action workflow runs automatically when you create the pull request! You should check that there are no eslint errors associated with the file that you translated and that the correctness tests still pass. *** Note that the GitHub action itself won't pass because the linter won't pass until both files are translated, i.e. both PRs are merged. *** This is OK! If you solved one of the linter errors, as indicated by GitHub actions, then you should still merge the branch back into
main
. - Assign the issue you created to the pull request
- Review your code (your teammates will likely do this in the future)
TypeScript Translation Resources
The following documentation pointers will help with the code changes you'll need to make - Exporting from Modules, Typing Functions, Express Req, Res types
Part 5a: Doing Code Reviews and Resolving Merge Conflicts¶
- Review your code (use the review change button). In this scenario, you won't be able to approve your changes since you created them. However, if they look good, you can move the next step! IF not, go and revise your code in your editor.
- Once your PR has been reviewed, merge your changes! Resolve any merge conflicts that arises accordingly
- Return to the Kanban board. If everything was set up correctly, the issue should automatically move into the Done column
Part 5b: Check GitHub Actions¶
- Click on the Actions tab on your
main
branch. If you have resolved all the issues correctly, the tests and linter should now pass, and a green check should show
Turning in the Assignment & Grading Rubric¶
Turn in Assignment 1 on Webcourses by providing a link to your forked GitHub Repo
The grading for this project will be broken down as follows:
- Part One: Forking & Github Actions - (10 points total)
- Part Two: Kanban Board & Issues - (10 points total)
- Part Three: Branching Committing & Pushing - (10 points total)
- Part Four: Writing Pull Requests - (10 points total)
- Part Five: Doing Code Reviews & Resolving Merge Conflicts - (10 points total)