Introduction to Version Control with Git

1. Introduction to Version Control with Git CSC/ECE 517, Spring 2017 A joint project of the CSC/ECE 517 staff, including Titus Barik, Gaurav Tungatkar, Govind Menon, and KrunalJhaveri

2. Local version control: RCS check out File Version 3 Version 2 • Keep many copies of files • Error prone • RCS stores deltas Version 1

3. Centralized Version Control • If you need to work with other programmers … Computer A File Version 3 check out Computer B Version 2 File check out Version 1

4. File Server vs. Version-Control Server At 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?

5. File-Sharing Issues The problem is that users are stepping on each other’s feet! Image: Version Control with Subversion

6. Approach 1: Lock, Modify, Unlock Locking may cause administrative problems. Locking may cause unnecessary serialization. Locking may create a false sense of security. Image: Version Control with Subversion

7. Approach 2: Copy-Modify-Merge Sounds chaotic, but in practice, runs extremely smoothly. Question: When is locking necessary? Image: Version Control with Subversion

8. Exercise 1 • Answer these questions • Give 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?

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

10. Traditional Repository Format A Subversion repository layout—typical of older version-control systems. The folder names are just a convention, and have no special meaning to the repository. Image: Version Control with Subversion

11. Creating a Branch—by Copying In Subversion, the underlying mechanism of a branch is implemented by performing a simple directory copy. Image: Version Control with Subversion

12. Exercise 2 • Answer these questionsabout 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?

13. Version 3 Version 2 Version 1 Version 3 Version 3 Version 2 Version 2 Version 1 Version 1 Distributed Version Control • Clients don’t checkout individual files; • they mirror therepository. • What’s theadvantage? Computer A Computer B File File

14. Git • Came 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)

15. Integrity & Checksums • Everything checksummed with an SHA-1 hash • 40-character string • composed of hex characters • calculated based on the contents of a file or directory structure in Git • Example • 24b9da6552252987aa493b52f8696cd6d3b00373 • But, you don’t have to type the whole SHA … • Git knows everything by hash, not filename

16. Snapshots, not Diffs • See 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 local • browse history • commit

17. 3 States of a File in Git • Modified • Staged • Committed working directory staging area git directory(repository) check out the project stage files commit

18. File Status Lifecycle untracked unmodified modified staged edit the file add the file stage the file remove the file

19. Checking Status • To 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 <file>..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track)

20. 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 <file>..." to unstage) # # new file: README # • For more info:http://git-scm.com/book/ch2-2.html

21. Remotes • On 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

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

23. Common Workflow using Git • Centralized workflow … • http://git-scm.com/book/ch5-1.html

24. Common Workflow using Git • Integration-manager workflow … • Common use cases: http://git-scm.com/book/ch5-2.html

25. Pull requests • After you’ve finished a project, you need to notify the maintainer. • This is done via a pull request. • You say which repository to pull from, and • give a summary of your changes. • http://git-scm.com/book/ch5-2.html

26. Guidelines for Commits • What 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 programmer’s changes.)

27. Repository code Your code … a = a + b … … a = c … • Is the difference because— • you changed a = c to a = a + b, • or because someone else changed • a = a + b to a = c • while you were working on your project?

28. Guidelines for Commits • Which is worse, • Downloading the repo as a zip file, and being scrupulously careful to make multiple commits with reasonable commit comments, or • Downloading the repo with its commit history, but committing your whole project in one commit? • Why? • Of course, you shouldn’t do either!

29. Guidelines for Commits • In 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.

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

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

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

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

34. Exercise 3, cont. $ git checkout master $ git merge [unityId] // merge changes from your branch back into master

35. Exercise 3, cont. Master branch Your new branch Local Commit 2 Commit 1 Commit 1.5 Commit 1 Commit 1 Commit 2 Commit 1 Commit 1.5 Remote (Origin)

36. Exercise 3, cont. Your new branch Local Commit 1.5 Commit 2 Commit 1 Commit 1.5 Commit 2 Commit 1 Commit 1.5 Commit 2 Commit 1 Remote (Origin)

37. Exercise 3, cont. Master branch Local Commit 1.5 Commit 2 Commit 1 Commit 1.5 Commit 2 Commit 1 Commit 1.5 Commit 2 Commit 1 Remote (Origin)