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. The easiest way to do this is to give each person on the team their own "personal work space" to make changes and managing how these changes get integrated together. GIT provides branches to manage this kind of work. However, inevitably, conflicts occur where people need to think about how best to resolve distinct changes to the same piece of code.

Getting Started

For this lab exercise, you must work together with someone else in the class.

• One person should fork the original lab_bounce repository into their own account to provide a place for the group can edit, commit, and push changes
• 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
• Both students should clone the one forked repository to their individual machines so they can work on their own separate copies
• Import the project into IntelliJ (New -> Project From Existing Sources) using the folder you just created
  For most of the dialogs, you can just accept the defaults by selecting Next, except the one for Libraries: in this one select your correct platform (by unselecting the other two platforms)
• Once the project window appears, you will need to a few more steps to get it to run:
  • Right click on the folder named resources and select Mark Directory As -> Resources Root
  • Select File -> Project Structure and then select Libraries within the dialog that appears
    Right click on the library there (it should be named after your platform: linux, mac, or win) and select Add to Modules
    Click OK in the dialog that appears and OK again to close the Project Settings dialog
  • Click to expand the folders src -> example to find the Java class ExampleBounce
  • Right click on this class to run it by selecting Run ExampleBounce.main()
• Run the program to verify that your Java installation is working.
  If there are compilation errors or it does not run, then the project is not correctly configured.

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.

Start within the single 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 the other person accept) a Merge Request from the master branch back to their personal branch
• each person will need to pull these changes back to their local machine as well after each one

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 Merge Requests are very useful 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 technology you use to manage your merges, we suggest this workflow in this course to minimize conflicts and maximize team involvement in the process of creating a combined codebase.

Decomposition: Extract a Class

Before starting the next part, work together within one person's copy of the code to refactor it to use a Bouncer class with the following methods:

• void move(double elapsedTime): changes the Bouncer's x- and y-coordinate by its speed dampened by the given elapsedTime
• void bounce(double screenWidth, double screenHeight): "bounces" off the walls represented by the edges of the screen by reversing the Bouncer's appropriate x or y speed value
  
• ImageView getView(): simply returns the Bouncer's ImageView instance variable so it can be added to the root node instead of the Bouncer itself

You should be able to do most of this simply by moving the existing code to a new class and then calling the new methods in place of the old code with the appropriate parameters.

Before continuing, use the suggested workflow to integrate the new version of the code with the other person's copy of the code.

Working Together, Working Apart

Continue practicing using the suggested workflow to complete the following tasks to get used to OpenJFX by having each person take one set of tasks and integrate the changes after each one is complete.

You may make any changes to the code you think are warranted (functional, organizational, or creating new classes) and feel free to discuss the changes with each other (either for better understanding OpenJFX or to avoid conflicts):

Person 1 Make the bouncer bounce off of all the walls, including the corners Make two bouncers (with random initial position and velocity) bounce off of all the walls Make a collection of many bouncers (with random initial position, size, and speed) bounce around

Person 2 Create the bouncer with a random initial position and speed Create the bouncer with a random initial size Refactor the code to create a class that can rotate in a given direction and change to a different color when colliding with any Bouncer that would be used to replace both the Grower and Mover rectangles

Resources

• GIT ready: Branching and Merging
• GIT Commands Summary Page

Submission

At the end of class, use Gitlab's Merge Request to submit your group's code to the original organization repository (note, there is no discussion file for this lab). Make sure the NetIDs of everyone in the group are in the title of your Merge Request and in comments within the main class.