Git Basics

Transcript

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

   View Slide

2. 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
   

   View Slide

3. What is Git
   

   View Slide

4. 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"
   

   View Slide

5. Who is Using Git
   

   View Slide

6. 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.
   

   View Slide

7. 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.
   

   View Slide

8. 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
   

   View Slide

9. 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
   

   View Slide

10. The Three States
    

    View Slide

11. 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.
    

    View Slide

12. First-Time Git Setup
    Identity
    $ git config --global user.name "John Doe"
    $ git config --global user.email johndoe@example.com
    Checking Your Settings
    $ git config --list
    Getting Help
    $ git help config
    

    View Slide

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

    View Slide

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

    View Slide

15. 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
    

    View Slide

16. 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 (!)
    

    View Slide

17. 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
    

    View Slide

18. 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'
    

    View Slide

19. 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
    

    View Slide

20. 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
    

    View Slide

21. 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
    

    View Slide

22. 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]
    

    View Slide

23. 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
    

    View Slide

24. 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
    

    View Slide

25. 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
    

    View Slide

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

    View Slide

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

    View Slide

28. 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(+)
    

    View Slide

29. 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.
    

    View Slide

30. 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
    contact : email.support@github.com
    =======
    
    please contact us at support@github.com
    
    >>>>>>> iss53:index.html
    

    View Slide

31. 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
    

    View Slide

32. A Successful Git Branching Model
    

    View Slide

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

    View Slide

34. Thank You for Attending
    Any questions?
    

    View Slide

35. 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
    

    View Slide