Introduction to Version Control with Git Acknowledgment Original

Introduction to Version Control with Git Acknowledgment: Original slides created in NC University by Titus Barik, Gaurav Tungatkar, Govind Menon, and Krunal Jhaveri 1

Book • https: //git-scm. com/book/en/v 2 • Ch 1 and Ch 2 2

Course On my webpage 3

History: Local version control File check out • Keep many copies of files • Error prone • Hard to manage Version 3 Version 2 Version 1 4

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

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? 6

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

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

Approach 2: Copy-Modify-Merge Sounds chaotic, but in practice, runs extremely smoothly. Image: Version Control with Subversion 9

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

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

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

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

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 – 24 b 9 da 6552252987 aa 493 b 52 f 8696 cd 6 d 3 b 00373 – But, you don’t have to type the whole SHA … • Git knows everything by hash, not filename 14

Snapshots, not Diffs • See http: //git-scm. com/book/ch 1 -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 15

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

File Status Lifecycle untracked unmodified staged edit the file add the file stage the file remove the file 17

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

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/ch 2 -2. html 19

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

Your code … a=a+b … Repository code … 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? 21

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! 22

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

Exercise in the lab. Clone a repository using the HTTPS clone url $ git branch // List branches modify $ git commit . . etc. 24