Lab Exercise: Using GIT in Teams

Work together as a team to practice working 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 — use this lab to practice dealing with these conflicts.

When working on a team project, you will need to develop a flow of working that minimizes potential conflict between each person's new code, while regularly integrating the team's work so no one gets too far behind. The easiest way to do this is to give each person on the team their own "personal work space" to make changes and manage how these changes get integrated together. In this course, we suggest this general workflow in this course which is similar to the common practice of "protecting" the master branch, minimizes merge conflicts, and maximizes team involvement in the process of creating a combined codebase.

Inevitably, conflicts will occur and they should be used as opportunities to think about and collaborate on how best to resolve distinct changes to the same piece of code.

Resources

• 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 Merge Conflicts

Everyone 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 master branch of your team project repository and make a series of tracked changes 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!

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

• each person should create (and the others accept) a Merge Request from their personal branch to the master branch
• each person should create and accept a Merge Request from the master branch back to their personal branch
• each person will need to pull these changes back to their respective branches on their local machine in order to work with the results

The command line takes place on your local machine, the Merge Requests take place on the Gitlab server, and each offers a different experience with the process of integrating the changes. We think using Merge Requests is helpful for integrating your changes with the team's code and allowing your team mate's to inspect those changes. You are welcome to use whichever style (command line or website) you are most comfortable with to manage your merges.

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)