CompSci 308
Spring 2024
Advanced Software Design and Implementation

Lab Exercise: Using GIT in Teams

In this part of the lab, work together in your Cell Society teams to practice using in branches, merging changes, and dealing with merge conflicts. By alternating edits to the same file, you will practice working in parallel and experiment with what kinds of changes GIT can process automatically and which changes must be merged by hand.


Experiment with Merging and Dealing with Conflicts

Each person will be making a lot of small edits (e.g., in comments or by creating new text files) so it may help to set little "goals" to keep track of what exactly you are trying to accomplish with each set of changes. If you have trouble coming up with your own goals, you can follow this exercise that makes a combined poem.

Start by creating a single file to edit, doc/, in the default main branch of your team project repository and push it to Gitlab. Then, with member of your team on the main branch locally: 

Do these steps multiple times until everyone feels comfortable dealing with conflicts (accepting all the changes, rejecting all the changes, or combining the changes).

Experiment with Branches

Now you will practice the course's suggested GIT Workflow for Teams.

For this part, do not merge any of your changes with the main branch. Also, make individual edits to one file common to all of your branches (such as doc/

Each person will create their personal branch to work on exclusively (in this lab and throughout the project):

git checkout -b YOUR_NAME_OR_NETID
in which you will make changes and interact with GIT "as usual":
git commit -m "A useful comment for your team mates about this change"

Experiment on your computer by making edits to existing files, creating and removing files, and moving between the main, team, branch and your personal branch using checkout (but not merge). Notice in IntelliJ how these files are updated (or added or removed!) automatically as you move between branches.

Do these steps multiple times until everyone feels comfortable moving between branches.

Practice Using Merge Requests

Each person will push their personal branch changes to Gitlab:

git push -u origin YOUR_NAME_OR_NETID

Then each person will create a Merge Request from their personal branch to the main, team, branch. The first person to do this should succeed with no problems (and someone should accept the Request)!

The next one should get the feedback that their Merge Request will not succeed due to a conflict. To fix this, you will need to update your personal code to be up to date with the team's code — and, in the process, fix the conflict. To update your personal code, you will need to merge the main, team, branch with your personal branch:

If you now visit your open Merge Request, and refresh the page, it should update automatically to note that the Request will succeed (and someone should accept the Request).

The last person should repeat this process as well, now integrating the changes from two teammates:

This way of integrating team changes with your personal changes allows you to run the code and ensure it behaves as expected before committing the merge or changing any code on the remote branch.

Try it Again Using Only Merge Requests

After each person is able to merge from their personal branch to main (and back) using the command line, take turns trying to do it again using only Merge Requests:

This way of integrating team changes with your personal changes can be more stream lined, especially if there are no conflicts. It also has the advantage that you do not need to switch between branches on your local computer.

More Practice

If you feel like you want more practice (now or later), try make more changes similar to these excellent online tutorials: