Reproducible Research 3 - Git
Wojciech Hardy
link: https://hackmd.io/@WHardy/RR-git2
Learn More →
How does it work? (quick recap)
Some additional info
How to deal with the line endings
Git Bash is stylised as a Unix environment.
In Unix: the end of a line is represented as a Line Feed (LF).
In Windows: the end of a line is represented by a carriage return (CR) and a line feed (LF). Hence CRLF.
By default, Git tries to settle the conflict for you (e.g. converts LF to CRLF when saving to Windows and the other way when saving in Git)
Most editors handle this anyway but the warning might be annoying
We can tweak some options
Change how automated conversion works:
git config --system core.autocrlf [true/false/input]
Change whether warnings should be issued:
git config --system core.safecrlf [true/false]
Provide specific rules on handling formats, by creating a .gitattribute file.
Cheatsheet: Basic commands
Cheatsheet: Advanced commands
Answering questions from last week
- What if we move our HEAD backwards?
Check this tutorial for an easy step-by-step description (the image comes from there)
Or try this one if you like X-Men - it's actually helpful (if you watched Days of Future Past)!
Typically HEAD points to the branch ("you're currently here").
Answering questions from last week
You can point it to an older commit instead: git checkout 87ec91d
This puts you in a "detached HEAD state".
Answering questions from last week
Here you can:
- panic and go back simply by redirecting it back to the branch, e.g.
git checkout master - check what was done in this commit
- create an alternate history:
(and turn it into a new branch if you want to keep it)
Answering questions from last week
- Grabbing only one file from a Git repository
Not that intuitive (Git sort of wants to look at whole snapshots), but here's how you can download single files from e.g. GitHub (and similar) repositories. E.g. if you accidentally delete something…
- What's up with single - and double – when writing terminal commands
It seems to be a remnant of two different conventions (one using single letters, and the other longer words), see here.
Git commands: working with a central repository
git init --bare to create barebones for a central repository (with no initial commits)
git clone [repo_name] [clone_name] to create a linked copy of the repo_name repository.
git fetch grab information about new commits/branches from the central repository.
git pull to grab the (new) commits from the central repository to our repository.
git push to put our (newly created) commits in the central repository.
We're going to pretend we have two developers and a central repository.
Quick recap
- In our workspace, let's create a new folder RR_git2 and go inside
mkdir RR_git2
cd RR_git2
- Let's create a repository named RecapRepo and go inside
git init RecapRepo
cd RecapRepo
git status
- Change local user.name to "RecapRepoUser"
git config --local user.name "RecapRepoUser"
- Create three files: commit the first; only stage the second; do nothing to the third
echo "this file will be commited" > file1.txt
echo "this file will be staged" > file2.txt
echo "this fille will be in the working directory" > file3.txt
git add file1.txt
git commit -m "Added file1.txt"
git add file2.txt
git status
- In RR_git2 create a clone of the first repository; go inside
cd ..
git clone RecapRepo RecapCloned
cd RecapCloned
- View the contents; check the status
ls
git status
- View the
configfile in the.gitfolder.
Exercise 5: simulating central repo with two locals
- In your RR_git2 directory create a new, bare repository called "CentralRepo"
git init CentralRepo --bare
- In your RR_git2 directory create a clone of the CentralRepo, named Dev1
git clone CentralRepo Dev1
- In your RR_git2 directory create a clone of the CentralRepo, named Dev2
git clone CentralRepo Dev2
- Set the local
user.namefor Dev1 repository to "Developer_1"
cd Dev1
git config --local user.name "Developer_1"
- Set the local
user.namefor Dev2 repository to "Developer_2"
cd ../Dev2
git config --local user.name "Developer_2"
So far all repositories are empty. Let's imagine:
- Dev1 kick-starts the project by creating the branch with one commit and sending it
upstream
echo "This will be the file with code" > code.R
git add .
git commit -m "Added the file with code"
git status
git push
git status
- Dev2 wants to get up-to-speed so grabs the changes
git pull
Divergence without conflicts
(graphs will appear later in the week)
Exercise 6: fetching and updating before pushing
- Create a readme.txt file in your Dev1 repository.
cd ../Dev1
echo "some text" > readme.txt
- Stage, commit and push the file.
git add .
git commit -m "Added readme.txt"
git push
- Go to the Dev2 repository.
cd ../Dev2
- Run
git status
git status
- Fetch information about changes from the central repository. Run
git status.
git fetch
git status
- Pull the information. Check folder contents.
git pull
ls (or in explorer/finder)
- Add a new line to readme.txt and create a readme.md file.
echo "another line" >> readme.txt
echo "a markdown readme file" > readme.md
- Stage, commit and push the file to the central repository.
git add .
git commit -m "Modified readme.txt and added readme.md"
git push
- In Dev1, create a text3.txt file with the line "A line added by Dev1". Stage, commit and push - what happens? Resolve the issue following the hints.
cd ../Dev1
echo "A line added by Dev1" > text3.txt
git add .
git commit -m "Dev1 created text3.txt"
git push (read the hints)
git pull (add a comment to the merge commit)
git push
Divergence with conflict - merging
(graphs will appear here later in the week)
Exercise 7: a merge conflict
Sometimes two different versions of a file exist. Git will try to make us merge them.
- In Dev2, create a new file called text3.txt with the line "A line added by Dev2". Stage, commit and push.
cd ../Dev2
echo "A line added by Dev2" > text3.txt
git add .
git commit -m "Dev2 creates a text3.txt file"
git push Git will tell us we need to do a pull first. Let's try that.
git pull (read the hints and go to step 2)
- There's a conflict because Dev1 committed a different text3.txt file earlier.
We're in a merging mode. We can edit the file (e.g. in Notepad) to figure out what should remain. Then stage it and commit it.
The merge becomes a new commit (try git log)
git commit -m "Merged two versions of text3.txt"
git push
Let's talk: BRANCHES
git branch [-l] list/create/delete branches
git checkout move the HEAD pointer (switch between branches)
git fetch sync cached branches with remote
git rebase [x] make a branch [x] start from a different point
git merge [x] combine two branches (by joining [x] to the current)
Stuck in VIM?
If you forgot about adding a message to your commit, you might have ended up in VIM. It's a free, text-editting software that sometimes feels like a trap.
Tl;dr: hit [ESC], then type *:q * and press Enter .
Repeat your commit with a helpful description.
You can also try adding the comment in VIM instead, and then exit with :wq instead, which should do the commit with the comment.
See more in this helpful Stackoverflow answer.
Useful links
Read more on the three trees with the git reset guideline
If you need more, just Google tutorials/blog posts/YouTube videos until you find one that makes it clear :) Lots to choose from!