Distributed Version Control

Transcript

1. Distributed Version
   control
   Git, Mercurial, Subversion, SVN..
   

   View Slide

2. Why a version control system?
   ● “Hey, Jane, could you send me a copy of those changes you made last
   Tuesday?”
   ● “Bob, this function doesn’t work anymore. Did you change something?”
   ● “Sorry, I can’t seem to find those old classes. I guess you’ll just have to
   re-implement them.”
   ● “OK, we’ve all been working hard for the last week. Now let’s integrate
   everyone’s work together.”
   

   View Slide

3. Features of a version control
   ● Basic functionality:
   ○ keep track of changes made to files (allows rollbacks)
   ○ merge the contributions of multiple developers.
   ● Benefits:
   ○ facilitates backups
   ○ increased productivity (vs manual version control)
   ○ encourages experimentation
   ○ makes source readily available – less duplicated effort
   ○ helps to identify/fix conflicts
   

   View Slide

4. Features of a version control (Conti.)
   ● Accountability:
   ○ who wrote the code?
   ○ do we have the rights to it?
   ● Support software engineering
   ○ hooks for peer reviews
   ● Software branches
   ○ different versions of software need to be maintained, ensure bug fixes shared.
   ● Record Keeping
   ○ Commit logs may tie to issue tracking system or be used to enforce guidelines
   

   View Slide

5. Different version controlling systems.
   ● Git is famous these days. Mercurial, Subversion and SVN were popular.
   ● Distributed VC (Git, mercurial) -- Many operations are local.
   

   View Slide

6. Git - Trivia
   ● Came out of Linux development community.
   ● Linus Torvalds, 2005.
   ● Initial goals:
   ○ Speed
   ○ Support for non-linear development (thousands of parallel
   branches)
   ○ Fully distributed
   ○ Able to handle large projects like Linux efficiently.
   

   View Slide

7. How is git different?
   Subversion Git - It takes snapshots!
   

   View Slide

8. Three areas of Git
   ● Unmodifed/modified files, staged files and commited files.
   

   View Slide

9. Git file lifecycle
   

   View Slide

10. Basic Workflow
    ● Modify files in your working directory.
    ● Stage files, adding snapshots of them to your staging area.
    ● Do a commit, which takes the files as they are in the staging area and stores
    that snapshot permanently to your Git directory.
    ● If a file is modified but has been added to the staging area, it is staged.
    ● If it was changed since it was checked out but has not been staged, it is
    modified.
    ● Remotes are used to locate remote repos.
    

    View Slide

11. So what is github?
    ● GitHub.com is a site for online storage of Git repositories.
    ● Many open source projects use it, such as the Linux kernel.
    ● You can get free space for open source projects or you can pay for private
    projects (get a student pack!!).
    ● Github is also a GSoC organization! Projects include atom, electron e.t.c.
    ● Alternatives bitbucket, gitlab e.t.c.
    ● Some organizations host on their own servers (why?).
    

    View Slide

12. Get ready to use Git!
    ● Install git!
    ● (First time?) Set the name and email for Git to use when you commit:
    ○ $ git config --global user.name “Bugs Bunny”
    ○ $ git config --global user.email bugs@gmail.com
    ● You can call git config –list to verify these are set.
    ● “--global” option.
    ● $ git config --global core.editor emacs (Vim is default)
    

    View Slide

13. Terms to know
    ● Repository
    ● Commit
    ● Branches and remotes
    ● Push, pull, fetch and rebase.
    ● Update and merge.
    ● Diff
    

    View Slide

14. Create a local copy of a repo.
    ● Two common scenarios: (only do one of these):
    1. To clone an already existing repo to your current directory:
    ○ $ git clone [local dir name]
    ● This will create a directory named local dir name, containing a working copy
    of the files from the repo, and a .git directory (used to hold the staging area
    and your actual repo)
    2. $ git init will create a .git directory in your current directory.
    

    View Slide

15. Git commands
    command description
    git clone url [dir] copy a git repository so you can add to it
    git add files adds file contents to the staging area
    git commit records a snapshot of the staging area
    git status view the status of your files in the working
    directory and staging area
    git diff shows diff of what is staged and what is
    modified but unstaged
    

    View Slide

16. Git commands (Conti.)
    git help [command] get help info about a particular command
    git pull fetch from a remote repo and try to merge into the
    current branch
    git push push your new branches and data to a remote repository
    others: init, reset, branch, checkout, merge, log, tag
    

    View Slide

17. Committing files
    ● The first time we ask a file to be tracked, and every time before we commit a
    file we must add it to the staging area:
    ○ $ git add README.txt
    ● This takes a snapshot of these files at this point in time and adds it to the
    staging area.
    ● To move staged changes into the repo we commit:
    ○ $ git commit –m “Fixing bug #22”
    ● These commands are just acting on your local version of repo.
    

    View Slide

18. Push, pull and rebase
    ● Add and Commit your changes to your local repo
    ● Pull from remote repo to get most recent changes (fix conflicts if necessary,
    add and commit them to your local repo)
    ● Push your changes to the remote repo
    ● Using rebase.
    

    View Slide

19. Pull requests and merge conflicts.
    ● Most important part in FOSS contributions.
    ● Can be better understood by a demo.
    

    View Slide

20. Branching
    ● Branch annotates which commit we are working on.
    

    View Slide

21. View Slide

22. View Slide

23. View Slide

24. View Slide

25. View Slide

26. View Slide

27. View Slide

28. View Slide

29. View Slide

30. Demo
    

    View Slide