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 Krunal Jhaveri 1

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

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

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?
Mininum needs: check code in/out, see history
Why do we need version control?
Permissions: You don’t have very good control over who can modify a file
Responsibility: If there’s 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 4 4

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

6. Approach 1: Lock, Modify, Unlock
Locking may cause administrative problems.
Locking may cause unnecessary serialization.
Locking may create a false sense of security.
If someone locks a file & leaves for the weekend, forgetting to unlock it. Admin needs to unlock it, but would rather not.
Developers can’t 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.
Image: Version Control with Subversion 6

7. Approach 2: Copy-Modify-Merge
Sounds chaotic, but in practice, runs extremely smoothly.
Question: When is locking necessary?
Where wouldn’t copy-merge-modify work well, & you would still need locking?
Consider editing a binary file, like audio. Ditto for images.
Image: Version Control with Subversion 7

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?
These questions should be fixed … # of interactions is useless. 8 8

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).
If branches work well, they should be merged back into the main project.
RTM: Release to mfg. (or mktg.)
Image: 9 9

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 10

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 11

12. Exercise 2 Answer 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?
Questions seem to be OK; could possibly add to them. 12

13. Distributed Version Control
Clients don’t check out individual files;
they mirror the repository.
What’s the advantage?
Computer A
Computer B
File
File
Version 3
Version 2
Version 1
Version 3
Version 2
Version 1 13

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) 14

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
24b9da aa493b52f8696cd6d3b00373
But, you don’t have to type the whole SHA …
Git knows everything by hash, not filename 15

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 16

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

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

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)
Have them do an example with “git add”. 19

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: 20

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), KiB, done. Resolving deltas: 100% (255/255), done. $ cd ticgit $ git remote origin 21

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

23. Common Workflow using Git
Centralized workflow … 23

24. Common Workflow using Git
Integration-manager workflow …
Common use cases: 24

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.
We might add more background info on why this is useful … 25

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.)
This can be fleshed out … 26

27. Your code Repository code Is the difference because— … 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? 27

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!
+ pulling in commits from other branches
+ mergetools
+ handling conflicts 28

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

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

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

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 commit -m “Commit message”
$ git push origin [unityId] // push on to the branch on the remote 32

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 33

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

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

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

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