Team workflow
Assign each team member a number 1 through 3 (or 4) and write your number down on a piece of paper. This lab will walk you through the basics of team workflow step-by-step.
Do the following exercises in order, following each step carefully.
Only one person at a time should type in the proposal.Rmd file and push updates.
Team member 1:
- Open the
proposal.Rmd file and change “Your Names” in the author of the YAML with your first and last name. Keep “Team Name:” as is.
- When you have finished, knit to PDF, then stage, commit, and push your
proposal.Rmd and PDF to GitHub with an appropriate commit message.
All the other team members:
- Once your team member has pushed the work, pull to get the updated documents from GitHub. Click on the
proposal.Rmd file and you should see the team name and the first team member’s name in the YAML.
Team member 2:
- It’s your turn. Add your name in the YAML next to the first team member’s name.
- When you have finished, knit to PDF, then stage, commit, and push your
proposal.Rmd and PDF to GitHub with an appropriate commit message.
All the other team members:
- Once your team member has pushed the work, pull to get the updated documents from GitHub. Click on the
proposal.Rmd file and you should see the team name and the first and last names of the first two team members in the YAML.
Team member 3:
- It’s your turn. Add your name in the YAML.
- When you have finished, knit to PDF, then stage, commit, and push your
proposal.Rmd and PDF to GitHub with an appropriate commit message.
All the other team members:
- Once your team member has pushed the work, pull to get the updated documents from GitHub. Click on the
proposal.Rmd file and you should see the team name and the first and last names of your team members in the YAML.
Team member 4:
- It’s your turn. Add your name in the YAML.
- When you have finished, knit to PDF, then stage, commit, and push your
proposal.Rmd and PDF to GitHub with an appropriate commit message.
All the other team members:
- Once your team member has pushed the work, pull to get the updated documents from GitHub. Click on the
proposal.Rmd file and you should see the team name and the first and last names of all team members in the YAML.
Merge conflicts (uh oh)
Before you begin, it’s important to know about merge conflicts.
Merge conflicts occur when two or more people are working on the same file at the same time.
When two collaborators make changes to the same file and push the file to their repository, git merges the two files.
If these two files have conflicting content on the same line, git will produce a merge conflict. Merge conflicts need to be resolved manually, as they require a human intervention:
To resolve the merge conflict, decide if you want to keep only your text, the text on GitHub, or incorporate changes from both texts. Delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes you want in the final merge.
Ultimately, the goal is to avoid merge conflicts. One way to do this is to ensure only one person is typing in the team’s R Markdown document at any given time.
See the FAQ with step-by-step instructions for troubleshooting a merge conflict.
Resolving a merge conflict
Some times merge conflicts still happen. To prepare for this scenario, let’s practice creating and resolving a merge conflict.
Team Member 4 should look at the team’s repo on GitHub to ensure that the other members’ files are pushed to GitHub after every step.
Step 1 (Team member 1): Change the team name to your team name and then knit, commit, and push.
Step 2 (Team member 2): Change the team name to something different (i.e., not your team name). Knit, commit, and push.
You should get an error.
Pull and review the document with the merge conflict. Read the error to your teammates. A merge conflict occurred because you edited the same part of the document as member 1. Resolve the conflict with whichever name you want to keep, then knit, commit manually in “Terminal” in RStudio (see FAQ) and push again.
Step 3 (Team member 3): Write some narrative in the space provided. You should get an error.
This time, no merge conflicts should occur, since you edited a different part of the document from members 1 and 2. Read the error to your teammates.
Click to pull. Then, knit, commit, and push. All merge conflicts should be resolved and all documents updated in the GitHub repo.