Distributed Version Control

Transcript

1. Distributed Version control Git, Mercurial, Subversion, SVN..
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.”
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
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
5. Different version controlling systems. • Git is famous these days. Mercurial, Subversion and SVN were popular. • Distributed VC (Git, mercurial) -- Many operations are local.
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.
7. How is git different? Subversion Git - It takes snapshots!
8. Three areas of Git • Unmodifed/modified files, staged files and commited files.
9. Git file lifecycle
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.
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?).
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)
13. Terms to know • Repository • Commit • Branches and remotes • Push, pull, fetch and rebase. • Update and merge. • Diff
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 <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.
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
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
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.
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.
19. Pull requests and merge conflicts. • Most important part in FOSS contributions. • Can be better understood by a demo.
20. Branching • Branch annotates which commit we are working on.
30. Demo