<style> .reveal { font-size: 26px; } </style> ## Reproducible Research: Git #2 <!-- Put the link to this slide here so people can follow --> link: https://hackmd.io/@mpalinski/rr-git2#/ main sources: - Krzysztof Kość's [materials]( http://coin.wne.uw.edu.pl/kkosc/02_Git.html#/git-intro-1) - https://git-scm.com/ --- ### Agenda - Git 101: consolidation - Visual summary of the basic operations from the last tutorial - More exercises! - Intro to remote repositories: Github/Gitlab --- ## Cheatsheet: Basic commands ![](https://i.imgur.com/AgWDtav.png) ---- ## Cheatsheet: Advanced commands ![](https://i.imgur.com/g25VecZ.png) --- ### Git 101: consolidation > Unlike the other VCS, Git has something called the "staging area" or "index". This is an intermediate area where commits can be formatted and reviewed before completing the commit. ![](https://i.imgur.com/Jk9X5WC.png =400x) *Source for this and following slides*: https://git-scm.com/ ---- > Git also makes it easy to ignore this feature if you don't want that kind of control — just add a '-a' to your commit command in order to add all changes to all files to the staging area. ![](https://i.imgur.com/Pyj0hx2.png) --- ### The three trees | Tree |Role | | -------- | -------- | | HEAD | Last commit snapshot | | Index | Proposed next commit snapshot | | Working directory | Sandbox | ---- ### HEAD HEAD is a snapshot of your last commit on a given branch. If you want to see what that snapshot looks like, simply type: `$ git cat-file -p HEAD` ---- ### Staging area aka Index The index is your proposed next commit. Command that shows you what your index currently looks like: `git ls-files` ---- ### Working directory Think of the working directory as a sandbox, where you can try changes out before sending them to your staging area (index) and then to history. --- ### Visual summary of the basic operations from the last tutorial #0 At this point, only the working directory tree has any content. ![](https://i.imgur.com/h3ZPQGp.png) ---- #1 We use `git add` to take content in the working directory and copy it to the index. ![](https://i.imgur.com/h7ZESGS.png) ---- #2 We run `git commit`, which takes the contents of the index and saves it as a permanent snapshot, creates a commit object which points to that snapshot, and updates master to point to that commit. ![](https://i.imgur.com/JptS5e9.png) ---- #3 If we run `git status`, we’ll see no changes, because all three trees are the same. ![](https://i.imgur.com/YBWWbYl.png) --- # Exercises! 🏋️‍♀️ --- ### Exercise 1 1. Using the --bare option initialize a new repo in a directory called server 2. Clone the server repository twice, name the clones client1 and client2 3. Add basic files inside the client1 repository (.gitignore, README.md, src/fun_do-nothing.R) 4. Commit and push the files, go to client2 repo and synchronize it. 5. Checkout the new branch feat/website. 6. Checkout the new branch, create a new dir called html with a new file index.html 7. Add some dummy content to the new file, stage and commit the change, publish the changes 8. Go to the client1 repository. Sync repo. 9. On master branch, commit a new file src/fun_do-something.R (let the function return its argument + 1). Push changes 10. Go to client2 repo. Synchronize it. Check the master branch 11. Checkout the feat/website branch and rebase it with master 12. Publish the changes, synchronize the client1 repo --- ### Exercise 2 1. Return to the client1 repo. Change the body of the src/fun_do-something.R function to return its argument + 2. 2. Amend the previous commit 3. Publish the commit 4. Publish the commit forcefully 5. Return to client2 repo. Sync the master branch 6. Checkout the feat/website branch, rebase it with updated master 7. Fix the conflicts, publish the changes forcefully --- ### Exercise 3 1. Remove client1, client2, server directories, re-run Exercise 1 2. Go to the client1 repo. Change the body of the src/fun_do-something.R function to return its argument + 2. 3. Amend the previous commit 4. Publish the commit 5. Publish the commit forcefully 6. Return to client2 repo. Sync the master branch 7. Checkout the feat/website branch, rename the argument of do_something function to y, stage and commit the change 8. Rebase the current branch with already updated master branch, fix arising conflicts 9. Check the branch status, publish the changes forcefully --- ### Exercise 4 1. Remove client1, client2, server directories, re-run Exercise 1 2. Go to the client1 repo. Change the body of the src/fun_do-something.R function to return its argument + 2. 3. Amend the previous commit 4. Publish the commit 5. Publish the commit forcefully 6. Return to client2 repo. Sync the master branch 7. Checkout the feat/website branch, rename the argument of do_something function to y, stage and commit the change 8. Merge the current branch with already updated master branch, fix arising conflict 9. Check the branch status, publish the changes normally --- ### Remote repos [![](https://i.imgur.com/NMOciRp.jpg =400x)](https://gitlab.com) [![](https://i.imgur.com/KYEPptc.png =400x)](https://github.com)
{"metaMigratedAt":"2023-06-15T20:56:15.702Z","metaMigratedFrom":"YAML","title":"Reproducible Research - GIT#2","breaks":true,"slideOptions":"{\"transition\":\"slide\"}","contributors":"[{\"id\":\"1c10bb23-6c4c-4c1b-8586-5f8d56305139\",\"add\":7,\"del\":10},{\"id\":\"8b999831-3930-4ead-8913-6e39a724b825\",\"add\":6733,\"del\":1356}]"}
    332 views
   Owned this note