Using GIT in Teams

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. GIT provides branches to manage this kind of work and integrates different branches through merging. However, inevitably, conflicts occur where people need to think about how best to resolve distinct changes to the same piece of code — this lab attempts to provide you a place to practice dealing with these conflicts.

Resources

If you have not already done this week's reading, GIT ready: Branching and Merging, it may be helpful to do it before starting. Commands Summaries are also good resources that is useful to have handy!

Lab Workflow

In your Cell Society teams, complete the following activities today:

1. On Gitlab, one person should fork the original project lab_browser into your own repository so you can edit, commit, and push your group's own changes
2. On Gitlab, on the resulting project web page, go to Settings → Members to add your partner so both people in the group can access the same repository
• Search for your partner's name and give them a Maintainer role in the project and choose Add to Project
3. In Terminal, all students should use git clone to copy the one, shared, forked repository to their individual machines so they can work on their own separate copies
4. In IntelliJ, all students should Open the cloned folder
5. As a group, alternate making edits to the same file to practice merging changes, dealing with merge conflicts, and working in branches
6. As a group, make specific changes to the browser code to both learn more about GUIs in OpenJFX and following a workflow to manage changes to the code as a team
   • In Terminal, practice using git push, git pull, and git merge directly as well as
   • On Gitlab, practice using Merge Requests online to do the merge between branches and git pull to bring changes into your branch on your machine
   • Repeat as many times as needed, letting each person try the changes/GIT steps in related chunks

Submission

At the end of class, use Gitlab's Merge Request to submit your group's poem and code back to the original organization repository's master branch to submit your group's progress. Do not worry about potential merge conflicts in this case, your request will not be approved.

Note, there is no discussion file for this lab but there should be a LOT of GIT commits!

Make sure the Title of your Merge Request is of the form "lab_browser - everyone's NetIDs".

Experiment with Merge Conflicts

For this part, both students 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 in the default master branch 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!

Once you have the basic idea of how to resolve a conflict, try creating separate branches (one for each person) and make more changes within your shared repository 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)

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 adding your changes to the team's code, but understand that it may be less clear for bringing their changes to your branch. Regardless of which style you use to manage your merges, we suggest this workflow in this course which is similar to the common practice of "protecting" the master branch, minimizing merge conflicts, and maximizing team involvement in the process of creating a combined codebase.

Working Together, Working Apart

Continue practicing using the suggested workflow to complete the following tasks by having each person take one set of tasks and integrating the changes after each one is complete. You are encouraged to discuss the changes with each other as you make them (either for better understanding OpenJFX or to avoid conflicts), but they should be coded independently. Note, the Model changes should be very small and easy to complete (so most of the time will be spent figuring out the View changes together) but doing them while the View changes will better help simulate working together in a project.