Introduction to Version Control with Git CSC/ECE 517, Fall 2014A joint project of the CSC/ECE 517 staff, including Titus Barik, Gaurav Tungatkar, Govind Menon, and Krunal Jhaveri

Local version control: RCSKeep many copies of filesError proneRCS stores deltasVersion 3Version 2Version 1Filecheck out

Centralized Version ControlIf you need to work with other programmers Version 3Version 2Version 1Filecheck outFilecheck outComputer BComputer A

File Server vs. Version-Control ServerAt first glance, the client-server architecture of a version-control system looks much like a typical file server.

So why do we need version control?

File-Sharing IssuesImage: Version Control with SubversionThe problem is that users are stepping on each others feet!

Approach 1: Lock, Modify, UnlockImage: Version Control with SubversionLocking may cause administrative problems.Locking may cause unnecessary serialization.Locking may create a false sense of security.

Approach 2: Copy-Modify-MergeImage: Version Control with SubversionSounds chaotic, but in practice, runs extremely smoothly.

Question: When is locking necessary?

Answer these questionsGive one advantage of using a version-control server for source-code management over using a fileserver.Explain how locking can cause administrative problems. Explain how locking can create a false sense of security.With copy-modify-merge, when is locking necessary? Exercise 1

Branches and Tags

Trunk: Location where main development occurs.Branches: Location used to isolate changes to another development line (e.g., experimental features).Tags: Snapshot of the content (e.g., RTM, service packs, EOL).Image: http://en.wikipedia.org/wiki/Subversion_(software)

Traditional Repository FormatImage: Version Control with SubversionA Subversion repository layouttypical of older version-control systems. The folder names are just a convention, and have no special meaning to the repository.

Creating a Branchby CopyingImage: Version Control with SubversionIn Subversion, the underlying mechanism of a branch is implemented by performing a simple directory copy.

Exercise 2Answer these questions about branches.Suppose, in fixing a bug, you modify three lines of code in two source files. Should you create a new branch? Why or why not? Which would probably be more common, branches or tags?What are some of the risks of copying files in a repository? How do version-control systems minimize this risk?

Distributed Version ControlClients dont check out individual files;they mirror the repository.Whats the advantage?FileFileComputer AComputer B

GitCame out of the Linux project, in 2005.Simple design Strong support for non-linear development (thousands of parallel branches) Fully distributed Able to handle large projects like the Linux kernel efficiently (speed and data size)

Integrity & ChecksumsEverything checksummed with an SHA-1 hash40-character string composed of hex characters calculated based on the contents of a file or directory structure in GitExample24b9da6552252987aa493b52f8696cd6d3b00373But, you dont have to type the whole SHA Git knows everything by hash, not filename

Snapshots, not DiffsSee http://git-scm.com/book/ch1-3.html Every time you commit, Git takes a snapshot of your files.Files that have not changed are not copied. Almost all ops are localbrowse historycommit

3 States of a File in GitModified Staged Committedworking directorystaging areagit directory (repository)check out the projectstage filescommit

File Status Lifecycleunmodifiedmodifiedstagededit the filestage the fileuntrackedadd the fileremove the file

Checking StatusTo check the status of your files:$ git status # On branch master nothing to commit (working directory clean)Creating new files $ vim README $ git status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track)

Checking status, cont.Begin to track the file:$ git add README The file is now tracked: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: README # For more info: http://git-scm.com/book/ch2-2.html

RemotesOn a project, you may be working with several remote directories.Origin is the server you cloned your repository from$ git clone git://github.com/schacon/ticgit.git Initialized empty Git repository in /private/tmp/ticgit/.git/ remote: Counting objects: 595, done. remote: Compressing objects: 100% (269/269), done. remote: Total 595 (delta 255), reused 589 (delta 253) Receiving objects: 100% (595/595), 73.31 KiB, done. Resolving deltas: 100% (255/255), done. $ cd ticgit $ git remote origin http://git-scm.com/book/ch2-5.html

Pulling, pushing to remote$ git fetch [remote-name]E.g., git fetch origingit push origin master

Common Workflow using GitCentralized workflow http://git-scm.com/book/ch5-1.html Integration-manager workflow Common use cases: http://git-scm.com/book/ch5-2.html

Pull requestsAfter youve finished a project, you need to notify the maintainer.This is done via a pull request.You say which repository to pull from, andgive a summary of your changes.http://git-scm.com/book/ch5-2.html

Guidelines for CommitsWhat happens if you download a repo in a zip file, do your project, then save it with a single commit?(Think of someone else trying to merge your changes with another programmers changes.)

Your codeRepository codea = a + ba = cIs the difference becauseyou changed a = c to a = a + b, or because someone else changeda = a + b to a = c while you were working on your project?

Guidelines for CommitsWhich is worse,Downloading the repo as a zip file, and being scrupulously careful to make multiple commits with reasonable commit comments, orDownloading the repo with its commit history, but committing your whole project in one commit?Why?Of course, you shouldnt do either!

Guidelines for CommitsIn your work, save the commit history.Each commit should be on one topic.A commit comment should be 1 line,certainly no more than one sentence.

Exercise 3Visit https://github.ncsu.edu/grmenon/versionControlClone the repository using the HTTPS clone url$ git clone [https_url] // clone an existing repo$ git branch // List branches

Exercise 3, cont.$ git branch$ git branch [unityId] // create a new branch from the current HEAD$ git branch $ git checkout [unityId] // switch to that branch

Exercise 3, cont.Add a new file (you can take a look at the test file and create a new test)$ git status$ git add [filename]$ git status$ git commit -m Commit message$ git push origin [unityId] // push on to the branch on the remote

Exercise 3, cont.[Pause here, until next week.]$ git fetch origin // Update other branches$ git merge origin/master //Merge any new changes on master into current branch

Exercise 3, cont.$ git checkout master

$ git merge [unityId] // merge changes from your branch back into master

Exercise 3, cont.Commit 1Commit 2Commit 1Your new branch

MasterbranchCommit 1Commit 2Commit 1Commit 1.5LocalRemote (Origin)Commit 1.5

Exercise 3, cont.Commit 1Commit 2Your new branch

LocalRemote (Origin)Commit 1.5Commit 1Commit 2Commit 1.5Commit 1Commit 2Commit 1.5

Exercise 3, cont.Commit 1Commit 2Master branch

LocalRemote (Origin)Commit 1.5Commit 1Commit 2Commit 1.5Commit 1Commit 2Commit 1.5

********Mininum needs: check code in/out, see historyWhy do we need version control? Permissions: You dont have very good control over who can modify a file Responsibility: If theres a bug, how do you know who cause it? VCSs have blame command (who last wrote a line) You may want to revert to an earlier version. Overlapping edits*****If someone locks a file & leaves for the weekend, forgetting to unlock it. Admin needs to unlock it, but would rather not.Developers cant work on different parts of the same file.Locks may have dependencies. A change to file B may also require a change to file A. Can cause deadlock.**Where wouldnt copy-merge-modify work well, & you would still need locking?Consider editing a binary file, like audio. Ditto for images.**These questions should be fixed # of interactions is useless.***If branches work well, they should be merged back into the main project.RTM: Release to mfg. (or mktg.)*******Questions seem to be OK; could possibly add to them.**************Have them do an example with git add.**********We might add more background info on why this is useful **This can be fleshed out ****+ pulling in commits from other branches

+ mergetools

+ handling conflicts******************