dikshashrestha/activity01-merge-conflicts

Activity 1 - Resolving Merge Conflicts

We will begin this activity as a whole class, then breakout into Teams. It is assumed that you have watched the videos contained within Preparation 1 and completed Preparation 2 to get GitHub and RStudio communicating.

In this activity, you will:

• Connect GitHub and RStudio and share files between these two tools.
• Edit and view changes in narrative text and R code chunks in an RMarkdown document.
• Create a branch within a GitHub repository.
• Fork a repository and make a pull request.
• Resolve merge conflicts caused when multiple users edit a file at the same time.

☑️ Task 1: Forking A Collaborative Poem

In this activity, we begin collaborating on coding projects. Collaborating on projects might be with you and colleagues or, simply, you and future you. Version control is one way to keep track of what a person did and when, which is much better than this system:

The Google Workspace (Drive, Docs, etc.) is a spectacular tool to use to collaborate on many different types of projects. Google even has a collaborating on coding notebooks (i.e., Google Colab); however, but is lacking in programming language options. We can think of GitHub as a Google Drive for collaborating on coding/software projects. Git would then be like Version History for a Google Doc.

Version control systems record the changes that are made each step of a project. This allows you to rewind to start at a previous version and play back through changes you made to eventually arrive at the most recent version. This is similar to what you did in your Learning Journal entry for Preparation 1.

Each time you make changes, you can (and should), provide a brief, yet informative commit message. This commit message is additional information that can be used to help keep track of what changes were made. There are many opinions on what needs to be included in commit messages. My recommendation is to use active terms and be brief, but say enough as to why this change was needed. Note that I do not always follow this recommendation (I get lazy too), but future me really appreciates it when current me is thoughtful.

A brief demonstration

Recall Daniel from The Coding Train’s video - he was working on a collaborative poem with different versions of himself. I am going give a brief demonstration that quickly goes through:

1. Connecting RStudio and GitHub,
2. Creating a branch in GitHub and making and committing changes on this branch,
3. Creating a branch in RStudio and making and committing changes on this branch,
4. Merging these branches to the main branch in GitHub.

To see Daniel from The Coding Train work through a similar process on his collaborative poem, checkout:

Planned Pause Point: If you have any questions, contact your instructor or another group.

☑️ Task 2: Talking with your neighbor(s)

From your Preparation 1, you saw that if you (individually) made changes to a branched version of your document, then merged those back into your main branch, there were no issues with the merge. In fact, two people could be editing the same file (on the same branch) and commit changes with no issues as long as the edits do not occur on the same line.

When resolving merge conflicts, we will be able to see each version of the file (along with these changes and the files, useful metadata about what changed, the complete history of committed changes make up a repository). This allows us to decide which changes we want to keep for the next version of the file. We can then keep these repositories in sync across different computers to help facilitate collaboration among different people (or versions of ourselves).

For the remainder of this activity, you will be working with your neighbor(s).

If you do not know your neighbor(s), introduce yourself!

Before we get into “doing” stuff, there are a four versions of the same document within the docs/ directory/folder of this activity repo:

1. day1.md,
2. day1.html
3. day1.pdf, and
4. day1.Rmd.

With your neighbor(s), explore how each file looks within your repository (click on them to view them within GitHub). Discuss with your neighbor(s) what is easily viewable and what is not. Keep this in mind as we progress through this semester.

Jenny Bryan provides some great information on repo browsability. Throughout this course, we will use my opinionated method of repo organization.

Aside

I am not too happy with my directions for resolving merge conflicts and honestly, I think this is too early in the semester to do this. Therefore, I will continue working on these for us to try later this semester. In the meantime, we will refine our Markdown skills.

☑️ Tasks 3: Complete the RMarkdown Document

For the rest of this class period, you will complete the RMarkdown document (activity0101-bechdel-test.Rmd) with your group members. Your instructor will continue circling through the groups and be available to help when needed.

1. In this GitHub repo, click on the Fork icon near the upper-right-hand corner. You should be taken a copy of this repo that is in your GitHub account - your page title should be {username}/activity01-merge-conflicts, where {username} is replaced with your GitHub username.
2. In the main repo page on GitHub, click on the green Code button. Verify that HTTPS is underlined in red on the pop-down, then copy the URL provided.
3. In RStudio, click on the icon (the icon below the Edit drop-down menu),
4. Click on Version Control on the New Project Wizard pop-up,
5. Click on Git and you should be on a “Clone Git Repository” page,
6. Paste the URL in the “Repository URL” text field,
7. The “Project directory name” text field should have automatically populated with activity0101-merge-conflicts. If yours did not, click into this box and press Ctrl/Cmd (usually this is a Mac issue);
8. In the “Create project as subdirectory of” field, click on Browse…. Navigate into your “STA 418” of “STA 518” (depending on what you created in Preparation 2), then within this folder, create a New Folder called “Activities”, think click Choose. Note that I am forcing you to use my file system management style.
9. Click on Create Project.

You are probably currently in the main branch (the drop-down menu next to the icon in the Git pane). We will continue working within your main branch, but I want you to notice that you can create new branches within RStudio!

In the Files pane, click on the activity0101-bechdel-test.Rmd. Update author: "Name" to your name.

Do not continue in this README document until after your group has completed the .Rmd file, then stage, commit, and push to this to your repo.

YOU DID IT!

Next: Activity 2 will cover creating visual representations of data.

Acknowledgement

Parts of this README are based on The Coding Train’s GitHub YouTube video series and The Carpentries’ Git training.