Slide 1

Slide 1 text

Git Basics $ git --distributed-is-the-new-centralized Mustafa Berkay Mutlu

Slide 2

Slide 2 text

Version Control Systems •Local data model (RCS) • All developers must use the same file system. •Client-server model (SVN, TFS) • Developers use a shared single repository. •Distributed model (Git, Mercurial) • Each developer works directly with his or her own local repository, and changes are shared between repositories as a separate step

Slide 3

Slide 3 text

What is Git

Slide 4

Slide 4 text

What is Git •Git is a fast, scalable, distributed revision control system •Open Source, GNU General Public License v2 •Written in a collection of Perl, C, and various shell scripts •Created by Linus Torvalds in 2005 for development of the Linux Kernel, he described the tool as "the stupid content tracker"

Slide 5

Slide 5 text

Who is Using Git

Slide 6

Slide 6 text

Git Under the Hood Conceptually, most other systems store information as a list of file-based changes. These systems think of the information they keep as a set of files and the changes made to each file over time.

Slide 7

Slide 7 text

Git Under the Hood Git thinks of its data more like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.

Slide 8

Slide 8 text

Git Has Integrity Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. Git uses SHA-1 hash: 24b9da6552252987aa493b52f8696cd6d3b00373

Slide 9

Slide 9 text

The Three States Git has three main states that your files can reside in: 1. Committed: data is safely stored in your local database 2. Modified: the file changed but have not committed it to your database yet 3. Staged: you have marked a modified file in its current version to go into your next commit snapshot

Slide 10

Slide 10 text

The Three States

Slide 11

Slide 11 text

The Three States The basic Git workflow goes something like this: 1. You modify files in your working tree. 2. You stage the files, adding snapshots of them to your staging area 3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Slide 12

Slide 12 text

First-Time Git Setup Identity $ git config --global user.name "John Doe" $ git config --global user.email [email protected] Checking Your Settings $ git config --list Getting Help $ git help config

Slide 13

Slide 13 text

Getting a Git Repository Creating a Repository $ git init Cloning a Repository $ git clone https://git.kernel.org/

Slide 14

Slide 14 text

Recording Changes to the Repository The lifecycle of the status of your files:

Slide 15

Slide 15 text

Recording Changes to the Repository Checking the Status of Your Files $ git status Tracking New Files $ git add readme.md Removing Files $ git rm readme.md

Slide 16

Slide 16 text

Ignoring Files Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. In such cases, you can create a file listing patterns to match them named .gitignore. ● Blank lines or lines starting with # are ignored. ● Standard glob patterns work ● You can start patterns with a forward slash (/) to avoid recursivity ● You can end patterns with a forward slash (/) to specify a directory ● You can negate a pattern by starting it with an exclamation point (!)

Slide 17

Slide 17 text

Ignoring Files Here is an example .gitignore file: # no .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a # only ignore the TODO file in the current directory, not subdir/TODO /TODO # ignore all files in the build/ directory build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt # ignore all .pdf files in the doc/ directory doc/**/*.pdf

Slide 18

Slide 18 text

Committing Your Changes The simplest way to commit $ git commit $ git commit -m "Story 182: Fix benchmarks for speed" Skipping the Staging Area $ git commit -a -m 'added new benchmarks'

Slide 19

Slide 19 text

Viewing the Commit History $ git log $ git log -p $ git log --stat $ git log --pretty=format:"%h - %an, %ar : %s" $ git log --pretty=format:"%h %s" --graph $ git log --since=2.weeks

Slide 20

Slide 20 text

Undoing Things At any stage, you may want to undo something. Be careful, because you can’t always undo some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong. $ git commit --amend

Slide 21

Slide 21 text

Working with Remotes List remotes $ git remote [-v | --verbose] Adding Remote Repositories $ git remote add pb https://github.com/paulboone/ticgit Removing Remotes $ git remote remove pb

Slide 22

Slide 22 text

Fetching from Your Remotes The fetch command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. $ git fetch [remote-name]

Slide 23

Slide 23 text

Pulling from Your Remotes If your current branch is set up to track a remote branch you can use the pull command to automatically fetch and then merge that remote branch into your current branch. $ git pull

Slide 24

Slide 24 text

Pushing to Your Remotes When you have your project at a point that you want to share, you have to push it upstream. $ git push origin master

Slide 25

Slide 25 text

Git Branching A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. $ git branch testing

Slide 26

Slide 26 text

Git Branching How does Git know what branch you’re currently on? It keeps a special pointer called HEAD.

Slide 27

Slide 27 text

Switching Branches This moves HEAD to point to the testing branch. $ git checkout testing

Slide 28

Slide 28 text

Merging Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your master branch. $ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)

Slide 29

Slide 29 text

Merge Conflicts Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging together, Git won’t be able to merge them cleanly. $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.

Slide 30

Slide 30 text

Merge Conflicts Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. <<<<<<< HEAD:index.html =======
please contact us at [email protected]
>>>>>>> iss53:index.html

Slide 31

Slide 31 text

Rebasing In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. $ git checkout feature $ git rebase master

Slide 32

Slide 32 text

A Successful Git Branching Model

Slide 33

Slide 33 text

Further Study • Branching Strategies and Workflows • Code Review Tools • GUI Clients • Github

Slide 34

Slide 34 text

Thank You for Attending Any questions?

Slide 35

Slide 35 text

References •Pro Git Book: https://git-scm.com/book/en/v2 •List of version control software: https://en.wikipedia.org/wiki/List_of_version_control_software