Practice Exercise: Using GIT in Teams

Work in pairs 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.

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.

Resources

• Git Branching: 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
• How to undo (almost) anything with GIT by Joshua Wehner
• GIT stashing and Cleaning from the Pro Git book

Experiment with Mistakes

No matter how experienced you become with GIT, at some point you will make a mistake an commit or push something you do not want in the repository. Certainly, making smaller commits and paying attention when you commit will always be the first and best defense against mistakes (as well as never using git add .). To that end, we recommend using these two GIT commands before all of your commits to ensure you know exactly what is being changed:

• git diff: show the differences between the current, edited, version of a file and the latest version in the repository
• git status: show the status of all files in the GIT folder (untracked, tracked and changed, or added for this commit)

However, once you have committed a mistake (pun intended), it is useful to be able to perform an "undo" — sometimes it will be possible to simply update the last action, but sometimes it may require creating a new commit that over writes previous changes. As long as the mistake is fixed, the history you leave is less of a concern for this course. Some GIT commands that will be useful include:

• git reset: rewinds your repository’s history all the way back to the specified commit, as if those commits never happened!
• git revert: create a new commit that is the opposite of a given commit
• git stash: save your modified tracked files on a stack of unfinished changes that you can reapply at any time
• git rebase: this is an advanced command, with many options, that attempts to smartly combine commits in a variety of ways. It is very popular (so you will see many articles about it) and very easy to mess up (so we do not recommend using it until you are very comfortable with GIT)

The above resource as well as this more humorous version have more details about each command, including different options for each.

With your partner, practice at least the following scenarios on this repository to practice making and fixing GIT mistakes:

• Undo the last commit
• Change the commit message of the last commit
• Make some changes and stash them, then make some more changes and commit them, then retrieve your stashed work and commit that
• Undo one of your bug fixes (so the code has that bug again)
• Remove the file .gitignore (note the leading period) from your project, then run the (terrible) command git add ., then see what was added using git status, finally undo the add by reseting the repository back to its latest version
• Stop GIT from tracking further changes to the README.md file (i.e., remove it from GIT's control)

Experiment with Merge Conflicts

Everyone will be making a lot of small simple 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 editing a single file, 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 other person 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 still feel like you want more practice (now or later), try make more changes similar to these excellent online tutorials:

• GIT Immersion (steps 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)