Step 2: Update your repo

Security tip!

There will be a point where you need to provide your GitHub username and password. The https://pod.w201rdada.org domain will use SSL encryption to protect your data in transfer, however it is prudent to not use the same password for a variety of services, especially cloud services. If you recycle passwords, you are making it much easier for identity thieves and hackers to rip you off!

We suggest you take advantage of GitHub security tokens that can serve as passwords with limited scope rather than using your normal GitHub password. Go to https://github.com/settings/tokens and create a token called “binder” (or whatever you like). Give it repository permissions only. Copy and paste the token to a local file for safe keeping and use it instead of your regular password when prompted by a pull or push.

If you use two-factor authentication for GitHub.com, you must set up a security token to be able to authenticate using RStudio Server.

To take advantage of RStudio’s git integration, start an RStudio Project.

From the RStudio Server instance you started at Step 1, click Project: (None) > New Project in the top right to start a new RStudio Project.

Use the Existing Directory option, leave the directory set to ~, and click Create Project.

Alternatively, do your git operations from RStudio’s terminal, commando style.

Jk git on the terminal does not save time, and you’ll enjoy the RStudio interface. But if you want to force yourself to practice git, skip setting up the project.¹⁰

If you commit and push the .Rproj file that is saved when you start a project, you can click it the next time you launch a binder instance and want to open a project to use git integration. When you launch a new pod as above, you start outside a project and need to open one to see git integration.
When a project is open, you will have a new Git tab in the upper right pane Environment|History|Connections|Build|Git because RStudio will detect your hidden .git directory.

Click the Git tab. Basic git operations are available with some buttons.
git push is an up arrow.
git pull is a down arrow.
git status occurs automatically and lists files with uncomitted changes.
git add happens if you click the checkbox next to a modified file.
git checkout happens if you select the branch name and choose another branch from the list.
git commit happens if you press Commit:
- The Review Changes pop-up window will open.
  You can check the boxes to stage changes.
  Add a message and press Commit to make a commit.
  Press History to review the commit tree.
git diff (pressing Diff) opens the same Review Changes pop-up.

These are for convenience, and you can observe the command line stdout when using them to learn how you would have done the same manually. More granular git operations must be done via the terminal.

If you see files listed under Git pane, these are the changes you will lose if your pod terminates! Remember you have 30 minutes after leaving your pod idle or closing the browser window. To access a closed pod, use your browser history to return to the most recent https://pod.w201rdada.org address. If you get a 404 then the instance is gone.

If you opened a project, RStudio modified the .gitignore file by adding the line *.Rproj.
.gitignore is a blacklist of files that you tell git not to track.
Right click on .gitignore in the Git pane and select Revert….
Click Yes. .gitignore is now in the state of the last commit (*.Rproj was removed).

Normally files listed in .gitignore will not show up in the Git pane.
On the command line, if you wanted to stage all changes for a commit you would normally use
git add . meaning “add the entire contents of the current directory”.
Files listed in .gitignore would not be added.

See your repository .gitignore for an example of how to use it as a whitelist instead of a blacklist.
To wit, click the Terminal tab next to your Console tab in the pane on the left (bottom left if you have a source file open). If the tab is missing, find it again under Tools.

Enter the following command to add some necessary updates from the repo you forked at the beginning of the term, which has in the meantime been modified:
```
git pull https://github.com/w201rdada/portfolio
```
Because you share a commit history with the base repo, the pull will be treated as merge from a branch.
Welcome to mergetown! You will see one of two things.
- The merge may automatically generate a commit and ask you to describe it with a message.
  If in the Terminal you see some text with a bunch of ~’s along the left edge, you’re in the vim text editor.
  Enter esc and type :wq to write the message and quit. This finalizes the merge commit.
  
  When using git on the command line, the RStudio Git pane may not update to reflect the changes you’ve made. Press the refresh arrow in the Git pane to force it to update.
- The merge may pause for manual intervention due to a conflict.
  Conflicts occur if the same line on each branch has been edited after the last common commit.
  Git will automatically insert lines of annotation in files to show you exactly where the ambiguities between branches occur.
  Somewhere, perhaps in multiple places, files mentioned with CONFLICT after git pull will have this in them:
```
<<<<<<< HEAD
line(s) from current branch
=======
line(s) from merging branch
>>>>>>> 1a2b3c4d5...
```
  Resolve the conflict by deciding what the lines should actually say.
  Be sure to delete all of the markup from all unmerged files. Files with conflicts will be listed with the status U in the Git pane.
  Commit your changes to finish the merge.
  
  Here HEAD is your current branch location (usually master) and the last long hash is the SHA1 id of the commit being pulled in. This markup is basically asking you to combine or choose between the content above and below the =======.
  
  It’s easy to find all of the merge conflicts.
  Use Edit > Find in files… and search for <<<<.
  Suffice to say the merge markups will break your code if you ignore them, or if it doesn’t break, something is going to look really weird on your web page!
  
  You are stuck in limbo during a merge conflict and some git operations won’t work until you resolve the conflict by making a commit.
You’ve done a lot of heavy merging.
After committing, it’s time to push those changes so they are safe.
Click the up arrow button in the Git pane.
Or use the Terminal with our good friends:
```
git add .
git commit -m'I totally fixed that merge conflict. I am so cool.'
git push origin master
```
You may have already made a commit. Doing it again won’t cause a problem, unless you don’t want your changes saved. All three lines are usually entered together to ensure that all local changes are pushed to the remote.
See what changed because of the merge.
Click Diff to open the Review Changes pop-up.
Click History.
Click down the list of commits to see what’s new.

You’re ready for Step 3: Hack away!

If you really want to get in the weeds, check out the Docker approach that we used before Binder came along!↩