git basics

why git?

If you've ever worked on a paper using Word, you've probably created a verison control system that works for you by saving a file with different "version" tags. The reason someone might do this is because they like having a backup of all their past changes. If someone wants to delete a paragraph, you keep a copy of the old version just in case And when you are collaborating with someone, this becomes more challenging. Tracking changes and merging content added by different people is time consuming. As you can imagine, this presents a problem in software development. It is likely that multiple people will work on the same file sometimes even at the same time. Even small software projects can have tens of files in multiple folders. Additionally, developers frequently experiment with features and this should never affect the "master" copy of the project

Text files

Most of the files we work with are just text.
Programmers have already figured out how to collaborate with text files: Version Control (e.g. git)!

git is a supplement to your workflow

workflow

Workflow

Edit files

$EDITOR

Save changes

git commit

Before we talk about git, let's talk about workflow. This is a simple example of a workflow. You edit a file and you save the file. SPC. Once you reach what you consider a stable state, you can save the file as a different name as backup, or save it on dropbox or however you usually implement a version control system When you use git however, you don't have to save a different version of the file. When you are ready to save the current version of the file as a backup, you do that in git by taking a snapshot of the current state. You can take a "snapshot" of the current state of a file by using a command called git commit. What really happens is that when you can create a "snapshot", it records the current state of all the files in the directory being tracked.

`git commit`

So what does a snapshot look like? Let's assume that a snapshot looks like this circle over here. As I mentioned earlier, a snapshot contains the current state of the file or directory. When git creates a snapshot, it also creates a number and attaches that number to it. git uses an algorithm to calculate this number and this number is unique, it is very unlikely that two such numbers will be the same Every snapshot / commit you create will have its own number attached to it. And this number is called a HASH. You can typically you can use the first 6 or 7 characters to uniquely identify a snapshot in your project. Let's say you have created this first commit, and now you make more changes to the file. and want to save them. When you make changes to your files, and save them using git commit, git creates a new snapshot with a new HASH. git also does a few other things. 1) It allows you to create a message that goes along with that commit. A commit has to have a message! 2) When a new commit is created, it saves a reference to the parent commit. A snapshot can have multiple parents - i.e. you can take changes from two commits and merge them into one. The current commit HASH number depends on the path, i.e. it depends on what the parent is. If you change the parent hash i.e. change the content in the parent, every commit hash after that will be different. 3) Whatever commit represents the current project state, git stores a reference to that current commit in the label HEAD In the word document VCS, we created multiple versions but we did not track how we got to each state. git allows us to do that by storing all this information You may be wondering, where does git store all this - we will get to that. This, as you can imagine, forms a graph.

What's your story

and like with any graph, you can choose to tell a story. In this case, we want to work on a feature of a software, and while working on it we get a new idea. You can go back to a previous state of the project, and branch off to work on a new idea - not affecting your current work. And, when you are ready, you can pull these changes back to your master branch You can go back and review individual changes made in any commit. You can even undo changes, apply these changes to different state of your project. You could also discard a branch entirely, or switch between branches. Branches are awesome, and we'll talk more able branches a little later. The point here is that this graph exists. This graph is the documentation of how your project came to be, i.e. the history of your project is a graph that you can traverse at will.

git history is a graph

Workflow

git init

Edit files

$EDITOR

Add changes

git add

Review status

git status

Save changes

git commit

Let's talk about our workflow again. To actually use git we need to add a couple of steps to the workflow we talked about earlier. We group changes before committing them. And we do this using the git add command. if we open a folder and try to "git add" a file, git will throw us an error. it doesn't know where to add the file to. We need to create a .git folder first and we do that using git init. You only need to do this once for a project, at the every beginning. If a project is already using git, then that .git folder exists and you can run any git command. the git add command, adds the content you specify to a "staging area" You can add multiple files at the same time to the staging area And then, when you call the git commit function, git takes everything that is in the staging area and pushes it into a new snapshot Think of the content in the staging area as the changes you would like your next snapshot to represent SPC Before you commit these changes to a new snapshot, you might want to review your changes. SPC git status is used to review your changes, SPC And to actually save this snapshot you can use git commit

demo

.git folder is the database of key value pairs that track your project history. You can start a git repository by typing `git init`. When you add a file, git runs a SHA1 hash on the file which returns a hash. This hash is stored in a tree object and a commit object. If you create a file on your machine called `readme` and write `# farm` in it, and `git add` it to an empty repo, you should get the following folder in your .git repo ├── b8 │ └── fa28116ec360ae79b59da237ca991ab31a696e Computes the hash of the file. Stores the contents of the README file using the hash of the file to name the file. Adds a reference to the README file to the git index because git only cares about content. git uses content as a heuristic to find if a file has been renamed. if too much of the content has been changed between two commits when a rename occured, git will think it is a different file. and you can manually set this heuristic, I believe the default is 50%. When you git commit the staged file, git creates a blob and a tree. git does calculate a diff though, only when it needs to push. Again, this can be set manually. You can say - take longer than you usually do, but make me the smallest patch you can.

Diff(erence)

Review status with git status

View changes with git diff

Track changes easily

Find who is to blame!

git blame

branches

`git branch master`

`git checkout -b feature`

`git checkout master`

`git merge master`

branches are just labels

Go back in time!

Find a commit you wanna go back to with

git log


commit c0f3b38e959fbd43888ffb0aed52289f0a0fd132 (HEAD -> gh-pages, origin/gh-pages, origin/HEAD)
Author: Eddie Schoute <censored@gmail.com>
Date:   Wed Nov 29 12:50:11 2017 -0500

	Added .gitignore

commit c0fvev3df94c763d23ec8d41b37a0e9e7e7ef39f
Author: Eddie Schoute <...@gmail.com>
Date:   Wed Nov 29 12:49:30 2017 -0500

	Added slides for newlines and diff.

then

git checkout c0fvev3

(partial matches are OK)

the remote

Collaborate with others.

Distributed Version Control

Everyone owns a full copy of the repository.
"The remote" is a special branch that tracks the state of the server.

Download changes?

`git pull`

Upload changes?

`git push`

If the remote has changed, get the changes with git pull before pushing.

git pull = git fetch + git merge

Remote is special branch, but a branch nonetheless

merge conflict

Uh-oh

Merges don't always go smoothly.
If git cannot figure out what to do: Merge conflict!

Remote animals.md:


								# Favorite animal
								Horse
								Dolphin

Local animals.md:


								# Favorite animal
								Horse
								Chicken

git pull gives a merge conflict!
git status:


							On branch master
							You have unmerged paths.
  					  	  	  (fix conflicts and run "git commit")
  					  	  	  (use "git merge --abort" to abort the merge)

							Unmerged paths:
  					  	  	  (use "git add <file>..." to mark resolution)

								both modified:   animals.md

							no changes added to commit (use "git add" and/or "git commit -a")

animals.md:


							# Favorite Animal
							Horse
							<<<<<<< HEAD
							Dolphin
							=======
							Chicken
							>>>>>>> branch1

Use your editor and fix manually:


							# Favorite Animal
							Horse
							Dolphin
							Chicken

Then

git add animals.md

and git commit

Review of big ideas

Track changes using git diff

Branches are just labels

Remote is a branch too

Resolve conflicts

Cheat Sheet

Run "git" (or git help <command>)

Summarized cheat sheet

git <command> (or just run "git" for help):

init: Initialise git repo.
status: Check status of repo. Use often!
add: Add a file to staging (before committing).
commit: Create a commit with your changes
pull: Pull changes from a remote repository.
push: Push changes to a remote repository.
branch: Create a branch.
merge: Merge a branch.
checkout: Switch to a branch.

Source code for this presentation

Forked from think-git by Dheepak Krishnamurthy