Adding a Partner¶
Students not working with a partner may ignore this section.
There are multiple ways to work on the same codebase for these assignments, but here’s our recommended way:
- Arbitrarily choose one of the two group members, and work in that member’s personal GitLab repository. It doesn’t matter which member you choose, since the code from project 0 will not be needed again.
- The chosen partner gives the other member access to their repository on GitLab. That partner should:
- Navigate to the Settings » Members page from the sidebar of their repository’s webpage on GitLab.
- Invite the other member (using their UW NetID) with Maintainer permissions. (Any role less permissive will not allow them to push to the master branch.)
- The other member clones the chosen member’s repository as described in project 0.
Afterwards, both partners should have the chosen member’s repository cloned and should be able to push and pull from the chosen partner’s GitLab repository.
Note
If your group decides to terminate the partnership after the assignment, the chosen member should revoke the other member’s access to their GitLab repository. (The other member should remember to pull one last time before this happens, so that they can manually copy the latest version of code into their own repo. Otherwise, the submitted code should still be accessible from Gradescope afterwards, but downloading the code this way may be more cumbersome than simply using Git.)
Pair Programming¶
When working on code in your group, we strongly recommend against trying to divide-and-conquer the separate sections of assignments. Not all sections require the same amount of time and effort, and sections of an assignment often depend on previous sections, so splitting work this way will likely reduce your ability to understand the assignment rather than saving any time.
Instead, we recommend pair programming—this will ensure that both parties contribute equally and that both parties know what the code does and how to use it later. Additionally, discussing and writing code together will greatly improve your ability to plan and debug as you work.
If you have 5–10 minutes, take a look at this document about pair programming. It has several tips and motivations for pair programming, and even includes a recap at the end if you only have 1 minute to spare.
Info
Due to the nature of an online quarter, you’ll need to pair program by screen-sharing through an online video calling application, such as Zoom.
Merging¶
If your group decides against pair programming for whatever reason and instead decides to work separately and simultaneously, you may need to pull and merge any new commits pushed to GitLab by your partner before you are able to push yourself.
Git will try to automatically attempt a merge when you pull: if the two sets of commits involve different files, it will just apply both sets; additionally, if both sets of changes alter different parts of the same file, Git will attempt to integrate both sets of changes automatically.
However, if both sets of changes touch the same line, you’ll need to manually resolve the merge; this is called a merge conflict. Check out IntelliJ’s page on resolving merge conflicts; there’s a nifty window that will pop up that should help you resolve these relatively pain-free. Also feel free to come to office hours if you have trouble with this stuff.
Warning
If you aren’t careful in this process and cancel the merge (e.g., by clicking “Abort”), your repository may be left in a half-merged state, which will prevent most Git functionality from working properly. If anything goes wrong, we recommend coming in to office hours for help unless you’re confident in your Git knowledge—Googling and trying random things may create more issues, and these things tend to be difficult to debug via the discussion board.
Getting the Assignment¶
Info
For those working in groups, only 1 member needs to go through this process. After that member pushes the changes, the other member can then acquire the changes by pulling normally (from the default origin remote). Having both members go through this process separately is likely to cause merge conflicts.
To get the skeleton (starter) code for the assignment, first open IntelliJ. IntelliJ should automatically open your most-recently-used project, which will likely be your personal repository for this class.
In the menu bar, tap on the VCS item, then hover over Git and tap Pull… in the submenu.
In the window that appears, change the “Remote” to skeleton and select skeleton/master in the “Branches to merge”. If there are no branches to merge, try tapping the refresh icon next to the remote to update the list of branches. Then, tap the blue Pull button to get the project skeleton code.
If using IntelliJ 2020.1 or later, your interface will look slightly different (see image below). Again, if there are no branches to merge after selecting skeleton then press Ctrl + F5 to refresh and it should appear.
Troubleshooting¶
If the deques folder that you just pulled isn’t bolded in the file explorer like cse143review, or you can’t seem to run any tests, it is likely that IntelliJ didn’t react to the change in time. We can manually ask it to reimport your project.
On the far right-hand side of IntelliJ, there’s a Gradle tool window that you can bring up. Click on “Reimport All Gradle Projects” (refresh button):
Now that you’ve acquired the assignment, let’s take a moment to go over how our regular project assignments are structured.
