class: title-slide # Econ 520: Data Science for Economists ## Lecture 2: Version control with Git and GitHub <br> <p align=center> Pedro H. C. Sant'Anna </p> <div style="margin-top: -.7cm;"></div> <p align=center> Emory University </p> <br> <p align=center> Spring 2024 </p> --- # Table of contents 1. [Prologue](#prologue) 2. [Git and GitHub](#git) 3. [Git(Hub) + RStudio](#rstudio) 4. [Git from the shell](#shell) 5. [Merge conflicts](#merge) 6. [Branches and forking](#branches) 7. [Other tips](#other) 8. [Summary](#summary) 9. [Appendix: FAQ](#faq) --- class: center, middle name: prologue # Prologue <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # Prologue - This lecture builds on Grant McDermott's [course materials](https://github.com/uo-ec607/lectures) (Lecture 2), from his time at the University of Oregon. We will even use his GIFs and his repository as illustrations. <div style="margin-top: 2.5cm;"></div> - I have made some modifications to the original materials, but the core content remains the same. --- # Before Next Class Before next class, I want you all to go through a software installation checklist: ☑ Instal [R](https://www.r-project.org/). ☑ Instal [RStudio](https://www.rstudio.com/products/rstudio/download/preview/). ☑ Instal [Git](https://git-scm.com/downloads). ☑ Create an account on [GitHub](https://github.com/). ☑ Instal [Visual Studio Code](https://code.visualstudio.com/download). ☑ Instal Python and R Extensions in VS Code (probably done in ECON 725). --- class: center, middle name: git # Git and GitHub <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # Why bother? <div align="center"> <img src="http://phdcomics.com/comics/archive/phd101212s.gif" height=500> </div> --- # Git(Hub) solves this problem ### Git - Git is a distributed version control system. (Wait, what?) - Okay, try this: Imagine if Dropbox and the "Track changes" feature in MS Word had a baby. - Git would be that baby. - In fact, it's even better than that because Git is optimised for the things that economists and data scientists spend a lot of time working on (e.g. code). - There is a learning curve, but I promise you it's worth it. --- # Git(Hub) solves this problem ### GitHub - It's important to realize that Git and GitHub are distinct things. - GitHub is an online hosting platform that provides an array of services built on top of the Git system. (Similar platforms include Bitbucket and GitLab.) - Just like we don't *need* Rstudio to run R code, we don't *need* GitHub to use Git. - You can integrate Github to VS Code, Rstudio, and other IDEs, too. - GitHub is a great place to share your work and collaborate with others. - It's also a great place to find other people's work and learn from them. --- # Git(Hub) for scientific research ### From software development... Git and GitHub's role in global software development is not in question. <div style="margin-top: -.5cm;"></div> - There's a high probability that your favourite app, program or package is built using Git-based tools. ### ... to scientific research Scientists and academic researchers are cottoning on too. - Benefits of version control and collaboration tools aside, Git(Hub) helps to operationalize the ideals of open science and reproducibility. - *Nature:* "[Democratic databases: science on GitHub](https://www.nature.com/news/democratic-databases-science-on-github-1.20719)" (Perkel, 2016). --- class: center, middle name: rstudio # Git(Hub) + RStudio <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # Seamless integration One of the (many) great features of RStudio is how well it integrates version control into your everyday workflow. <div style="margin-top: -.5cm;"></div> - Even though Git is a completely separate program to R, they feel like part of the same "thing" in RStudio. - This next section is about learning the basic Git(Hub) commands and the recipe for successful project integration with RStudio. -- I also want to bookmark a general point that we'll revisit many times during this course: <div style="margin-top: -.5cm;"></div> - The tools that we're using all form part of a coherent data science ecosystem. - Greatly reduces the cognitive overhead associated with traditional workflows, where you have juggle multiple programs and languages at the same time. --- # Link a GitHub repo to an RStudio Project The starting point for our workflow is to link a GitHub repository (i.e. "repo") to an RStudio Project. Here are the steps we're going to follow: <div style="margin-top: -.3cm;"></div> 1. Create the repo on GitHub and initialize with a README. 2. Copy the HTTPS/SSH link (the green "Clone or Download" button). 3. Open up RStudio. 4. Navigate to **File -> New Project -> Version Control -> Git**. 5. Paste your copied link into the "Repository URL:" box. 6. Choose the project path ("Create project as subdirectory of:") and click **Create Project**. --- # Link a GitHub repo to an RStudio Project <div style="margin-top: 1.5cm;"></div> Now, I want you to practice by these steps by creating your own repo on GitHub — call it "test" — and cloning it via an RStudio Project. <div style="margin-top: 1.5cm;"></div> See my GIF walk through on the next slide. --- # Link a GitHub repo to an RStudio Project <div align="center"> <img src="pics/git-create-repo.gif" height=500> </div> --- # Make some local changes Look at the top-right panel in your RStudio IDE. Do you see the "Git" tab? - Click on it. - There should already be some files in there, which we'll ignore for the moment. Now open up the README file (see the "Files" tab in the bottom-right panel). - Add some text like "Hello World!" and save the README. - Do you see any changes in the "Git" panel? Good. (Raise your hand if not.) <div style="margin-top: 1.5cm;"></div> Again, see my GIF walk through on the next slide... --- # Make some local changes <div align="center"> <img src="pics/git-local-change.gif" height=500> </div> --- # Main Git operations Now that you've cloned your first repo and made some local changes, it's time to learn the four main Git operations. <div style="margin-top: -.5cm;"></div> 1. **Stage** (or "add") - Tell Git that you want to add changes to the repo history (file edits, additions, deletions, etc.) 2. **Commit** - Tell Git that, yes, you are sure these changes should be part of the repo history. 3. **Pull** - Get any new changes made on the GitHub repo (i.e. the upstream remote), either by your collaborators or you on another machine. 4. **Push** - Push any (committed) local changes to the GitHub repo --- # Main Git operations <div style="margin-top: 2.5cm;"></div> For the moment, it will be useful to group the first two operations and last two operations together. <div style="margin-top: 2.5cm;"></div> They are often combined in practice too, although you'll soon get a sense of when and why they should be split up. <div style="margin-top: 2.5cm;"></div> -- Ready for more GIFs? --- # Stage and Commit <div align="center"> <img src="pics/git-stage-commit.gif" height=450> </div> -- Note the helpful commit message to ourselves. --- # Push and Pull <div align="center"> <img src="pics/git-push-pull.gif" height=430> </div> -- See [here](https://ohi-science.org/manual/#rpostback-askpass-error) if you get `Error: unable to read askpass response from 'rpostback-askpass'`. --- # Recap Here's a step-by-step summary of what we just did. - Made same changes to a file and saved them locally. <div style="margin-top: .3cm;"></div> - *Staged* these local changes. <div style="margin-top: .3cm;"></div> - *Committed* these local changes to our Git history with a helpful message. <div style="margin-top: .3cm;"></div> - *Pulled* from the GitHub repo just in case anyone else made changes too (not expected here, but good practice). <div style="margin-top: .3cm;"></div> - *Pushed* our changes to the GitHub repo. <div style="margin-top: 1cm;"></div> .hi[Note:] Always pull from the upstream repo *before* you push any changes. Seriously, do this even on solo projects; making it a habit will save you headaches down the road. --- # Why this workflow? Creating the repo on GitHub first means that it will always be "upstream" of your (and any other) local copies. <div style="margin-top: 1cm;"></div> - In effect, this allows GitHub to act as the central node in the distributed VC network. <div style="margin-top: 1cm;"></div> - Especially valuable when you are collaborating on a project with others — more on this later — but also has advantages when you are working alone. <div style="margin-top: 1cm;"></div> - If you would like to move an existing project to GitHub, my advice is still to create an empty repo there first, clone it locally, and then copy all your files across. --- # Why this workflow? RStudio Projects are great. <div style="margin-top: 1cm;"></div> - Again, they interact seamlessly with Git(Hub), as we've just seen. <div style="margin-top: 1.5cm;"></div> - They also solve absolute vs. relative path problems, since the .Rproj file acts as an anchor point for all other files in the repo. <div style="margin-top: 1.5cm;"></div> - And you know that calling files from `YourComputer/YourName/Documents/Special-Subfolder/etc` in your scripts makes you a bad person, right? --- class: center, middle name: shell # Git from the shell <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # Why bother with the shell? The GitHub + RStudio Project combo is ideal for new users. <div style="margin-top: -.5cm;"></div> - RStudio's Git integration and built-in GUI cover all the major operations. - RStudio Projects FTW. However, I want to go over Git <a href="https://happygitwithr.com/shell.html?q=shell#shell" target="_blank">shell</a> commands so that you can internalize the basics. - The shell is more powerful and flexible. Does some things that the RStudio Git GUI can't. - Potentially more appropriate for projects that aren't primarily based in R. <br> (Although, no real harm in using RStudio Projects to clone a non-R repo.) - Also, you'll need to use the shell if you want to use Git on a remote server (e.g. HPC). --- # Main Git shell commands Clone a repo. ```bash $ git clone REPOSITORY-URL ``` <div style="margin-top: 1.5cm;"></div> See the commit history (hit spacebar to scroll down or q to exit). ```bash $ git log ``` <div style="margin-top: 1.5cm;"></div> What has changed? ```bash $ git status ``` --- # Main Git shell commands (cont.) Stage ("add") a file or group of files. ```bash $ git add NAME-OF-FILE-OR-FOLDER ``` You can use [wildcard](https://ryanstutorials.net/linuxtutorial/wildcards.php) characters to stage a group of files (e.g. sharing a common prefix). There are a bunch of useful flag options too: - Stage all files. ```bash $ git add -A ``` - Stage updated files only (modified or deleted, but not new). ```bash $ git add -u ``` --- # Main Git shell commands (cont.) - Stage new files only (not updated). ```bash $ git add . ``` - Commit your changes. ```bash $ git commit -m "Helpful message" ``` - Pull from the upstream repository (i.e. GitHub). ```bash $ git pull ``` - Push any local changes that you've committed to the upstream repo (i.e. GitHub). ```bash $ git push ``` --- class: center, middle name: merge # Merge conflicts <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # Collaboration time Turn to the person next to you. You are now partners. (Congratulations.) <div style="margin-top: 1cm;"></div> - P1: Invite P2 to join you as a collaborator on the "test" GitHub repo that you created earlier. (See the *Settings* tab of your repo.) <div style="margin-top: 1cm;"></div> - P2: Clone P1's repo to your local machine.<sup>1</sup> Make some edits to the README (e.g. delete lines of text and add your own). Stage, commit and push these changes. <div style="margin-top: 1cm;"></div> - P1: Make your own changes to the README on your local machine. Stage, commit and then try to push them (*after* pulling from the GitHub repo first). <div style="margin-top: -.5cm;"></div> .footnote[<sup>1</sup> Change into a new directory first or give it a different name to avoid conflicts with your own "test" repo. Don't worry, Git tracking will still work if you change the repo name locally.] --- # Collaboration time Did P1 encounter a `merge conflict` error? - Good, that's what we were trying to trigger. - Now, let's learn how to fix them. --- # Merge conflicts Let's confirm what's going on. ```bash $ git status ``` As part of the response, you should see something like: ```bash Unmerged paths: (use "git add <file>..." to mark resolution) * both modified: README.md ``` Git is protecting P1 by refusing the merge. It wants to make sure that you don't accidentally overwrite all of your changes by pulling P2's version of the README. Overall, `git status` can provide a helpful summary to see which files are in conflict. --- # Merge conflicts (cont.) Okay, let's see what's happening here by opening up the README file. RStudio is a good choice, although your preferred text editor is fine.<sup>1</sup> You should see something like: ```bash # README Some text here. <<<<<<< HEAD Text added by Partner 2. ======= Text added by Partner 1. >>>>>>> 814e09178910383c128045ce67a58c9c1df3f558. More text here. ``` .footnote[<sup>1</sup> Other good choices are <a href="https://code.visualstudio.com/" target="_blank">VS Code</a> or <a href="https://atom.io/" target="_blank">Atom</a>, which both support native Git(Hub) integration. You can set your preferred default editor with `$ git config --global core.editor "PREFERRED_EDITOR"`.] --- # Merge conflicts (cont.) What do these symbols mean? ```bash # README Some text here. <<<<<<< HEAD Text added by Partner 2. ======= Text added by Partner 1. >>>>>>> 814e09178910383c128045ce67a58c9c1df3f558. More text here. ``` --- count: false # Merge conflicts (cont.) What do these symbols mean? ```bash # README Some text here. *<<<<<<< HEAD Text added by Partner 2. ======= Text added by Partner 1. >>>>>>> 814e09178910383c128045ce67a58c9c1df3f558. More text here. ``` <div style="margin-top: 1.5cm;"></div> - `<<<<<<< HEAD` Indicates the start of the merge conflict. --- count: false # Merge conflicts (cont.) What do these symbols mean? ```bash # README Some text here. <<<<<<< HEAD Text added by Partner 2. *======= Text added by Partner 1. >>>>>>> 814e09178910383c128045ce67a58c9c1df3f558. More text here. ``` <div style="margin-top: 1cm;"></div> - `<<<<<<< HEAD` Indicates the start of the merge conflict. - `=======` Indicates the break point used for comparison. --- count: false # Merge conflicts (cont.) What do these symbols mean? ```bash # README Some text here. <<<<<<< HEAD Text added by Partner 2. ======= Text added by Partner 1. *>>>>>>> 814e09178910383c128045ce67a58c9c1df3f558. More text here. ``` <div style="margin-top: 1cm;"></div> - `<<<<<<< HEAD` Indicates the start of the merge conflict. - `=======` Indicates the break point used for comparison. - `>>>>>>> <long string>` Indicates the end of the lines that had a merge conflict. --- # Merge conflicts (cont.) Fixing these conflicts is a simple matter of (manually) editing the README file. <div style="margin-top: 1.5cm;"></div> - Delete the lines of the text that you don't want. <div style="margin-top: 1.5cm;"></div> - Then, delete the special Git merge conflict symbols. <div style="margin-top: 1.5cm;"></div> Once that's done, you should be able to stage, commit, pull and finally push your changes to the GitHub repo without any errors. --- # Merge conflicts (cont.) Caveats: - P1 gets to decide what to keep because they fixed the merge conflict. <div style="margin-top: 1cm;"></div> - OTOH, the full commit history is preserved, so P2 can always recover their changes if desired. <div style="margin-top: 1cm;"></div> - A more elegant and democratic solution to merge conflicts (and repo changes in general) is provided by Git **branches**. <div style="margin-top: 1cm;"></div> - We'll get there next. <div style="margin-top: 1cm;"></div> --- # Aside: Line endings and different OSs ### Problem During your collaboration, you may have encountered a situation where Git is highlighting differences on seemingly unchanged sentences. <div style="margin-top: -.5cm;"></div> - If that is the case, check whether your partner is using a different OS to you. The "culprit" is the fact that Git evaluates an invisible character at the end of every line. This is how Git tracks changes. (More info [here](https://help.github.com/articles/dealing-with-line-endings/) and [here](https://en.wikipedia.org/wiki/Newline).) - For Linux and MacOS, that ending is "LF". - For Windows, that ending is "CRLF" (of course it is...) --- # Aside: Line endings and different OSs ### Solution Open up the shell and enter ```bash $ git config --global core.autocrlf input ``` (Windows users: Change `input` to `true`). --- class: center, middle name: branches # Branches and forking <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # What are branches and why use them? Branches are one of Git's coolest features. - Allow you to take a snapshot of your existing repo and try out a whole new idea *without affecting* your main (i.e. "master") branch. - Only once you (and your collaborators) are 100% satisfied, would you merge it back into the master branch. <div style="margin-top: -.5cm;"></div> - This is how most new features in modern software and apps are developed. - It is also how bugs are caught and fixed - But researchers can easily — and should! — use it to try out new ideas and analysis (e.g. robustness checks, revisions, etc.) - If you aren't happy, then you can just delete the experimental branch and move on. --- # Create a new branch in RStudio <div align="center"> <img src="pics/git-new-branch.gif" height=500> </div> --- # Branch shell commands Create a new branch on your local machine and switch to it: ```bash $ git checkout -b NAME-OF-YOUR-NEW-BRANCH ``` <div style="margin-top: 1cm;"></div> Push the new branch to GitHub: ```bash $ git push origin NAME-OF-YOUR-NEW-BRANCH ``` <div style="margin-top: 1cm;"></div> List all branches on your local machine: ```bash $ git branch ``` --- # Branch shell commands (cont.) Switch back to (e.g.) the master branch: ```bash $ git checkout master ``` <div style="margin-top: 1cm;"></div> Delete a branch ```bash $ git branch -d NAME-OF-YOUR-FAILED-BRANCH $ git push origin :NAME-OF-YOUR-FAILED-BRANCH ``` --- # Merging branches + Pull requests You have two options: ### 1. Locally - Commit your final changes to the new branch (say we call it "new-idea"). <div style="margin-top: 1cm;"></div> - Switch back to the master branch: `$ git checkout master` <div style="margin-top: 1cm;"></div> - Merge in the new-idea branch changes: `$ git merge new-idea` <div style="margin-top: 1cm;"></div> - Delete the new-idea branch (optional): `$ git branch -d new-idea` --- # Merging branches + Pull requests You have two options: ### 2. Remotely (i.e. *pull requests* on GitHub) - PRs are a way to notify collaborators — or yourself! — that you have completed a feature. <div style="margin-top: 1cm;"></div> - You write a summary of all the changes contained in the branch. <div style="margin-top: 1cm;"></div> - You then assign suggested reviewers of your code — including yourself potentially — who are then able to approve these changes ("Merge pull request") on GitHub. <div style="margin-top: 1cm;"></div> - Let's practice this now in class... --- # Your first pull request You know that "new-idea" branch we just created a few slides back? Switch over to it if you haven't already. <div style="margin-top: 1cm;"></div> - Remember: `$ git checkout new-idea` (or just click on the branches tab in RStudio) Make some local changes and then commit + push them to GitHub. <div style="margin-top: 1cm;"></div> - The changes themselves don't really matter. Add text to the README, add some new files, whatever. --- # Your first pull request (cont.) After pushing these changes, head over to your repo on GitHub. - You should see a new green button with "Compare & pull request". Click it. - Add a meta description of what this PR accomplishes. You can also change the title if you want. - Click "Create pull request". - (Here's where you or your collaborators would review all the changes.) - Once satisfied, click "Merge pull request" and then confirm. --- # Your first pull request (cont.) <div align="center"> <img src="pics/git-pr.gif" height=500> </div> --- # Forks Git forks lie somewhere between cloning a repo and branching from it. <div style="margin-top: 1cm;"></div> - In fact, if you fork a repo then you are really creating a copy of it. <div style="margin-top: 1cm;"></div> Forking a repo on GitHub is [very simple](https://help.github.com/articles/fork-a-repo/); just click the "Fork" button in the top-right corner of said repo. <div style="margin-top: 1cm;"></div> - This will create an independent copy of the repo under your GitHub account. <div style="margin-top: 1cm;"></div> - Try this now. Use one of [my repos](https://github.com/pedrohcgs?tab=repositories) if you can't think of anyone else's. --- # Forks (cont.) Creating forks is super easy as we've just seen. However, maintaining them involves some more leg work if you want to stay up to date with the original repo. <div style="margin-top: 1.5cm;"></div> - GitHub: "[Syncing a fork](https://help.github.com/articles/syncing-a-fork/)" <div style="margin-top: 1.5cm;"></div> - OTOH, this isn't going to be an issue for completed projects. <div style="margin-top: 1cm;"></div> - E.g. Forking the repo that contains the code and data of a published paper. --- class: center, middle name: other # Other tips <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # README README files are special in GitHub because they act as repo landing pages. <div style="margin-top: 1.5cm;"></div> - For a project tied to a research paper, this is where you should be explicit about the goal of the research paper, the software requirements, how to run the analysis, and so forth (e.g. [here](https://github.com/grantmcdermott/bycatch)). <div style="margin-top: 1.5cm;"></div> - On the other end of the scale, many GitHub repos are basically standalone README files. Think of these as version-controlled blog posts (e.g. [here](https://github.com/jfiksel/github-classroom-for-teachers)). --- # README README files can also be added to the *sub-directories* of a repo, where they will act as a landing pages too. - Particularly useful for bigger projects. Say, where you are using multiple programming languages (e.g. [here](https://github.com/grantmcdermott/blueparadox)), or want to add more detail about a dataset (e.g. [here](https://github.com/grantmcdermott/sceptic-priors/tree/master/data)). <div style="margin-top: 1.5cm;"></div> READMEs should be written in Markdown, which GH automatically renders. - We'll talk about [Markdown](https://www.markdownguide.org/) (and its close relation, [R Markdown](https://rmarkdown.rstudio.com/)) during the course of our homework assignments. --- # .gitignore A .gitignore file tells Git what to — *wait for it* — ignore. <div style="margin-top: 1cm;"></div> This is especially useful if you want to exclude whole folders or a class of files (e.g. based on size or type). <div style="margin-top: 1cm;"></div> - Proprietary data files should be ignored from the beginning if you intend to make a repo public at some point. <div style="margin-top: 1cm;"></div> - Very large individual files (>100 MB) exceed GitHub's maximum allowable size and should be ignored regardless. See <a href="https://docs.github.com/en/repositories/working-with-files/managing-large-files/" target="_blank">here</a>. --- # .gitignore (cont.) I typically add compiled datasets (e.g. CSV) to my .gitignore in the early stages of a project. <div style="margin-top: 1cm;"></div> - Reduces redundant version control history, where the main thing is the code that produces the compiled dataset, not the end CSV in of itself. ("Source is real.") <div style="margin-top: 1cm;"></div> - Simple to remove from my .gitignore once the project is being finalized (e.g. paper is being submitted). --- # .gitignore (cont.) You can create a .gitignore file in multiple ways. <div style="margin-top: 1.5cm;"></div> - A .gitignore file was automatically generated if you cloned your repo with an RStudio Project. <div style="margin-top: 1.5cm;"></div> - You could also have the option of adding one when you first create a repo on GitHub. <div style="margin-top: 1.5cm;"></div> - Or, you can create one with your preferred text editor. (Must be saved as ".gitignore".) --- # .gitignore (cont.) Once the .gitignore file is created, simply add in lines of text corresponding to the files that should be ignored. - To ignore a single a file: `FILE-I-WANT-TO-IGNORE.csv` - To ignore a whole folder (and all of its contents, subfolders, etc.): `FOLDER-NAME/**` - The standard shell commands and special characters apply. - E.g. Ignore all CSV files in the repo: `*.csv` - E.g. Ignore all files beginning with "test": `test*` - E.g. Don't ignore a particular file: `!somefile.txt` --- # GitHub Issues [GitHub Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) are another great way to interact with your collaborators and/or package maintainers. <div style="margin-top: 1.5cm;"></div> - Issues are basically a way to track bugs, feature requests, or other to-do items. <div style="margin-top: 1.5cm;"></div> - If you spot any problems with any of my own repos, please feel free to open an issue. I'll try to respond as quickly as possible. --- class: center, middle name: summary # Summary <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # Recipe (shell commands in gold) 1. Create a repo on GitHub and initialize with a README. 2. Clone the repo to your local machine. Preferably using an RStudio Project, but as you wish. (E.g. Shell command: `$ git clone REPOSITORY-URL`) 3. .hi[Stage any changes you make:] `$ git add -A` 4. .hi[Commit your changes:] `$ git commit -m "Helpful message"` 5. Pull from GitHub: `$ git pull` 6. (Fix any merge conflicts.) 7. Push your changes to GitHub: `$ git push` --- class: center, middle name: faq # Appendix: FAQ <html><div style='float:left'></div><hr color='#EB811B' size=1px width=1100px></html> --- # FAQ **Q: When should I commit (and push) changes?** **A: Early and often.** - It's not quite as important as saving your work regularly, but it's a close second. - You should certainly push everything that you want your collaborators to see. **Q: Do I need branches if I am working on a solo project?** **A: You don't *need* them, but they offer big advantages in maintaining a sane workflow.** - Experiment without any risk to the main project! - If you combine them with pull requests, then you can compress significant additions to your project (which may comprise many small edits) into a single branch. --- # FAQ (cont.) **Q: What's the difference between cloning and forking a repo?** **A: Cloning directly ties your local version to the original repo, while forking creates a copy on your GitHub (which you can then clone).** - <a href="https://happygitwithr.com/fork-and-clone" target="_blank">Cloning</a> makes it easier to fetch updates (and is often the best choice for new GitHub users), but <a href="https://happygitwithr.com/fork-and-clone" target="_blank">forking</a> has advantages too. **Q: What happens when something goes wrong?** **A: Think: "Oh shit, Git!"** - Seriously: http://ohshitgit.com/. --- # FAQ (cont.) **Q: What happens when something goes <i>horribly</i> wrong?** **A: Burn it down and start again.** - http://happygitwithr.com/burn.html - This is a great advantage of Git's distributed nature. If something goes horribly wrong, there's usually an intact version somewhere else. --- # FAQ (cont.) <div align="center"> <img src="https://imgs.xkcd.com/comics/git_2x.png" height=500> </div>