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.

Resources

• GIT Workflow for Teams suggested in this course
• Git Branching and Merging: it may be helpful to do this week's reading before starting
• Command Cheatsheet: a GIT command summary is a useful resource to keep handy

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/MERGE_PRACTICE.md, 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: 

• in parallel, each person should make a tracked change using the standard GIT commands (add and commit):
• take turns using git push and git pull to understand how to integrate each person's changes and how make (and avoid making) conflicts when combining your changes
• spend time reading the messages GIT gives when it rejects your push or notes a conflict when you pull — also try following some of the advice given in these messages!

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/MERGE_PRACTICE.md).

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 add YOUR_UPDATED_FILES
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:

• In your Terminal, change into the main branch to pull down the new changes
  

      git checkout main
      git pull origin main

• This merge should proceed smoothly since you have not made any local changes to the main branch
• Change back into your personal branch to merge the new changes now in the main branch
  

      git checkout BRANCH_NAME
      git merge main

• This is where the conflicts will appear and you will decide how to fix them and create a commit just for the fixes and push it up to Gitlab as usual

      git add YOUR_UPDATED_FILES
      git commit -m "A useful comment for your team mates about this change"
      git push -u origin BRANCH_NAME

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:

• pull and merge the team updates with their personal code
• fix the merge conflicts and push the changes to Gitlab
• accept the proposed Merge Request

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:

• each person will create (and the others accept) a Merge Request from their personal branch to the main branch
• each person will create and accept a Merge Request from the main branch back to their personal branch
• each person will pull the merged changes to the personal branch on their local computer
  

  git checkout -b YOUR_NAME_OR_NETID
  git pull

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:

• GIT Immersion (labs 24-30): a straight forward series of steps
• Learn GIT Branching (levels 1-4): an interactive game and visualization (highly recommended if you ever need more practice working with GIT)