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

Distributed Version Control

February 13, 2016

Distributed Version Control


February 13, 2016

More Decks by Sricharan

Other Decks in Technology


  1. 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.”
  2. 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
  3. 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
  4. Different version controlling systems. • Git is famous these days.

    Mercurial, Subversion and SVN were popular. • Distributed VC (Git, mercurial) -- Many operations are local.
  5. 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.
  6. 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.
  7. 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?).
  8. 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 [email protected] • You can call git config –list to verify these are set. • “--global” option. • $ git config --global core.editor emacs (Vim is default)
  9. Terms to know • Repository • Commit • Branches and

    remotes • Push, pull, fetch and rebase. • Update and merge. • Diff
  10. 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 <url> [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.
  11. 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
  12. 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
  13. 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.
  14. 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.
  15. Pull requests and merge conflicts. • Most important part in

    FOSS contributions. • Can be better understood by a demo.