Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Getting Started With GIT

Getting Started With GIT

Loknan Nanyaks talk for forLoop Google Hangout July 2016 on Getting Started with GIT

forLoop

July 16, 2016
Tweet

More Decks by forLoop

Other Decks in Programming

Transcript

  1. VCS / SCM Source control / Version control is the

    management of changes to documents, computer programs and other collections of information git is a source code management system.
  2. DATA REDUNDANCY AND REPLICATION Since there are multiple full repositories

    on multiple machines (instead of one central repository), the risk of project loss due to server failure or some other catastrophe is much lower. HIGH AVAILABILITY High availability -- Server down? Network down? No problem. Work in your repo (commit, view history, branch, etc) to your heart's content. Try that with Subversion!
  3. SUPERIOR DISK UTILIZATION AND NETWORK PERFORMANCE Git efficiently compresses the

    objects in the .git directory, saving you space. COLLABORATION FRIENDLY Git makes it easy to collaborate on projects with groups of contributors and with great services like Bitbucket, Gitlab and (of course) Github, git's collaboration friendliness is even further magnified.
  4. INITIALIZING A GIT REPO $ git init A git repo

    is usually a directory that is tracked by git. Git tracks the states of the files in the directory and with various commands, informs you of the status of you repository. To start tracking a directory (to initialize a git repo):
  5. How git thinks about its data. * One key difference

    that we need to mention a bit is the way git thinks about data in comparison to how other VCS. Most other systems (CVS, Subversion, Perforce etc.) store information as a list of file-based changes fig: file-based changes
  6. * 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. fig: changes as snapshots
  7. Simply put, a branch in Git is a lightweight movable

    pointer to a commit. Commits are snapshots of your repository. These snapshots usually contain/reference other git object types. COMMITS BRANCHES
  8. The image shows how a commit is represented in the

    repository Pointer to that root tree and all the commit metadata
  9. Git status Arguably the most typed command on the git

    cli, it displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working tree and the index file, and paths in the working tree that are not (yet) tracked by Git (and are not ignored by ‘gitignore’) $ git status
  10. Git add In order to begin tracking a new file,

    you use the command git add. What this command does is to update the ‘index’ using the current content found in the working tree to prepare the content stages for the next commit. $ git add <file_name> Suppose you have a lot of changes in a file and you don’t want to commit all the changes at once: $ git add <file_name> -p The ‘-p’ flag interactively chooses chunks in the file to add to the ‘index’ or staging area.
  11. Git commit Stores the current contents of the index in

    a new commit along with a log message from the user describing the changes. $ git commit If you have changes in the working directory and you really want to add all files with a simple commit message $ git commit —amend To change/update the last commit - in the event that you don’t like the commit message or to add another file to the same commit. $ git commit -am “my super awesome commit message” * Note that any file you have in the index gets added when you use this commit option and yeah, it rewrites history so use carefully.
  12. $ git cat-file -p <commit_sha> Since we should now have

    a commit, lets take a minute to examine it - or any random commit on your system
  13. After a few hours of moving bits around and a

    bunch of commits, our repo ‘kinda’ looks like this *conceptually* Remember: Git thinks of its data more like a set of snapshots of a miniature filesystem
  14. *The “master” branch in Git is not a special branch.

    It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don’t bother to change it. Which when looked at from a birds eye view, looks ‘something’ like this:
  15. * By default, the `git branch` command makes the tip

    of the branch the HEAD Now we have 2 branches pointing to the same commit object f30ab…
  16. $ git checkout master $ git branch testing $ git

    show-ref master $ git show-ref testing Let’s confirm that both branches actually point to the same commit object * We’ll talk a bit about ‘checkout’ soon.
  17. Since we’ve seen that a branch is simply a pointer

    to a commit object - identified by a ‘sha’, it’s fairly easy to select commits as bases for our new branches. $ git branch <branch_name> [<start-point>] (source: man git-branch) Creating a branch with a start point. $ git branch feature/authentication-patch 34ac55…
  18. HEAD How does Git know what branch you’re currently on?

    Easy, It keeps a special pointer called HEAD The HEAD is just a pointer to the currently checked out branch. $ cat .git/HEAD
  19. CHECKOUT Git checkout is a very useful command that alters

    the working tree. Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch. It moves HEAD to a different branch (or commit) and updates the working directory to match it. $ git checkout <branch_name>
  20. Note that any uncommitted change will be lost during a

    checkout so Git forces you to stash or commit before checking out to another branch. This is also the reason why when you need to remove the changes made on a file you use: $ git checkout <file_name>
  21. Detached HEAD The HEAD becomes ‘detached’ when you checkout to

    a valid commit that isn’t a branch. $ git checkout 34ac55… This can be used to quickly check inspect an old version of your project. * Being in the ‘detached head’ state can however be dangerous because if you checkout to a grandparent of HEAD for instance and then make commits, you loose being able to get back the commits even after switching to other branches.
  22. • Blobs The git “blob” type is just a bunch

    of bytes that could be anything, like a text file, source code, or a picture, etc. • Trees A git tree is like a filesystem directory. A git tree can point to, or include Git “blob” objects or other git trees. • Commits A git commit object includes: Information about who committed the change/check-in/commit, a pointer to the git tree object that represents the git repository when the commit was done and the parent commit to this commit (so we can easily find out the situation at the previous commit). • Tags A git tag object points to any git commit object. A git tag can be used to refer to a specific tree, rather than having to remember or use the hash of the tree.
  23. Inside .git HEAD config description hooks pre-push.sample post-update.sample pre-commit.sample info

    objects refs [ a text file that is shown as project description in web frontend ] [ repository wide configuration ] [ text file showing currently checked out branch ] [ where git hooks are stored ] * Git hooks are scripts that run automatically every time a particular event occurs in a Git repository [ use this file to ignore files (like .gitignore but isn’t versioned) ] exclude [ Git’s internal warehouse for blobs, indexed by SHAs - where the ’objects’ are stored ] [ Where refs (including) branches live ] heads remotes tags stash [ where your git branches are managed ] [ remote branches ] [ … here be the tags ] [ an ascii text file that has your stash SHAs ]
  24. Git clone The git clone command copies an existing Git

    repository to a new directory. The “working copy” is a full-fledged Git repository—it has its own history, manages its own files, and is a completely isolated environment from the original repository. $ git clone <repo_url> <repo_url> must be a valid ssh, git, ftp or http(s) url
  25. …or even on a flash drive $ git clone /<path_to_source>

    /<new_path> $ git clone /path/to/source/repo /path/on/flash/drive You can clone from and to your local filesystem. * of course, the flash drive should be mounted
  26. Git merge The git merge command incorporates changes from the

    named commits (since the time their histories diverged from the current branch) into the current branch Say we have a repository with 2 branches as shown below: * see the git documentation for more options ( http://git-scm.com/book)
  27. $ git checkout master $ git merge iss53 Instead of

    just moving the branch pointer forward, Git creates a new snapshot that results from this merge and automatically creates a new commit that points to it. This type of commit referred to as a merge commit, and is special in that it has more than one parent. The above commands leave our repository in a new state. fig: merge commit
  28. Merge conflicts Sometimes, the merge between 2 branches may not

    go smoothly and you’ll have something called a merge conflict. $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. If your changes on the iss53 branch modified the same part of a file as a new change on the branch being merged unto, you’ll get a merge conflict.
  29. $ git status On branch master You have unmerged paths.

    (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a”) Running ‘git status’ will give some insight into what is happening. Despite trying to merge branches, we still have ‘unmerged paths’. This is a merge conflict and git status shows the files that have conflicts under ‘Unmerged Paths’.
  30. Git helps in resolving conflicts by adding conflict-resolution markers to

    the files that have conflicts, so you can open them manually and resolve those conflicts. Resolving Conflicts Your file will contain sections that have markers and the conflicted file will look something like: <<<<<<< HEAD:index.html <div id="footer">contact : [email protected]</div> ======= <div id="footer"> please contact us at [email protected] </div> >>>>>>> iss53:index.html * you can then stage your updated files and commit to complete the merge.
  31. Git show This command shows you information about a git

    object - commits, blobs, stashes, branches etc. $ git show [<branch_name>] | [<sha>] Git blame Show what revision and author last modified each line of a file. The blame command is a Git feature, designed to help you determine who made changes to a file. $ git blame <file_name> * see the git documentation for more options ( http://git-scm.com/book)
  32. Git cherry-pick Apply the changes introduced by some existing commits.

    You’ll often find, when using branches, how easy it is to commit to a different branch (say, testing branch) than the one intended (master). $ git cherry-pick testing [ apply to the current branch the change introduced at the tip of the testing branch ] $ git cherry-pick testing..hotfix [ apply to the current branch the changes introduced in ‘hotfix’ that are not in ‘testing’ ] * see the git documentation for more options ( http://git-scm.com/book)
  33. Git reset git reset is used to move the tip

    of the branch to a different commit. This can be used to remove commits from the current branch. Recall: when you checkout a branch, it changes HEAD to point to the new branch ref, populates your Index with the snapshot of that commit, then copies the contents of the Index into your Working Directory. file.txt has been modified and the repo is in a clean state. For instance, if we had our repository as such,
  34. $ git reset —-soft HEAD^ ** Reset always moves what

    HEAD points to. That means, from a clean repo, if we’re on the master branch and we run git reset 93536a4, master will point to 9e5e6a4.
  35. $ git reset —-mixed HEAD^ ** Reset always moves what

    HEAD points to. That means, from a clean repo, if we’re on the master branch and we run git reset —mixed 93536a4, master will point to.