Git: (Distributed) Version Control

Size: px

Start display at page:

Download "Git: (Distributed) Version Control"

Jayson Lloyd
6 years ago
Views:

1 Git: (Distributed) Version Control Computer Science and Engineering College of Engineering The Ohio State University Lecture 2

2 The Need for Version Control Track evolution of a software artifact Development is often non-linear Older versions need to be supported Newer versions need to be developed Development is non-monotonic May need to undo some work, go back to an older version, or track down when a mistake was introduced Facilitate team-based development Multiple developers working on a common code base How can project be edited simultaneously?

3 Key Idea: A Repository Repository= working tree + store + index Warning: "Repository" often (incorrectly) used to mean just the store part! Working tree = project itself Ordinary directory with files & subdirectories Store = history of project Hidden directory: don t touch! Index = virtual snapshot Gateway for moving changes in the working tree into the store History = DAG of commits Each commit represents a complete snapshot of the entire project

4 File Structure of a Repository ~/mashup/ css/ buckeye-alert-resp.css demo.css demo-js.html Gemfile Gemfile.lock.git/ index...etc....gitignore Rakefile README.md...etc...

5 Conceptual Structure working tree ~/mashup/ store ~/mashup/.git/ ind index ~/mashup/.git/index

6 A History of Commits commit b revision β d's parent is c working tree ~/mashup/ store ~/mashup/.git/ ind index ~/mashup/.git/index

7 History is a DAG Every commit (except the first) has 1 or more parents e has 1 parent Initial commit has no parents e h i has 2 parents a b d g i c f j k store

8 Example View of DAG

9 Example View of DAG $ git log --oneline --graph * clean up css * d579fa2 merge in improvements from \ * 0f10869 replace image-url helper in css * b595b10 add buckeye alert notes * a6e8eb3 add raw buckeye alert download / * b4e201c wrap osu layout around content * e9d3686 add Rakefile and refactor schedule loop * 515aaa3 create README.md * eb26605 initial commit

10 Commit Each commit is identified by a hash 160 bits (i.e., 40 hex digits) Practically guaranteed to be unique Can use short prefix of hash if unique $ git show --name-only c252f6924baa17c9b84a4c1baaed438b Author: Paul Sivilotti <user.pags@server.fake> Date: Mon Mar 31 15:30: clean up css source/stylesheets/_site.css

11 History is a DAG A better picture would label each commit with its hash (prefix) eca7 96c9 d1bf c0a2 850a df2f 8f59 a21a 512a But in these slides we abbreviate the hash id's as just: 'a', 'b', 'c'

12 Nomenclature: Branch Branch: a pointer to a commit Different from "branch" in DAG's shape rankings a b d g i c f j k store

13 Nomenclature: : a special reference, (usually) points to a branch rankings a b d g i c f j k store

14 Nomenclature: Useful to think of as being "attached" to a particular branch rankings a b d g i c f j k store

15 View of DAG with Branches $ git log --oneline --graph --decorate * ( -> ) clean up css * d579fa2 (alert) merge in improvements from \ * 0f10869 replace image-url helper in css * b595b10 add buckeye alert notes * a6e8eb3 add raw buckeye alert download / * b4e201c wrap osu layout around content * e9d3686 add Rakefile and refactor schedule loop * 515aaa3 create README.md * eb26605 initial commit

16 A "Clean" Repository same ("wd clean") $ git status On branch nothing to commit, working directory clean same ("nothing to commit") δ ind

17 Edit Files in Working Tree Add files, remove files, edit files now differs from index δ ind

18 Edit Files in Working Tree Add files, remove files, edit files now differs from index $ git status On branch Changes not staged for commit: modified: css/demo.css δ ind

19 Add: Working Tree Index $ git add --all. index =, both differ from ind

20 Add: Working Tree Index $ git add --all. index =, both differ from $ git status On branch Changes to be committed: modified: css/demo.css ind

21 Commit: Index Store $ git commit advanced (with attached branch!) new commit added to store e unaffected (but now clean) Store changed! DAG extended parent is old ind

22 The (New) State of Repository e ind

23 Creating a New Branch $ git branch fix e fix ind

24 Checkout: Changing Branch $ git checkout fix e moved Store unaffected (apart from ) Same DAG, branches fix ind

25 Checkout: Changing Branch $ git checkout moved e now same as Advice: checkout only when is clean fix ind

26 Edit Files in Working Tree Add files, remove files, edit files e now differs from index fix ind

27 Add & Commit: Update Store $ git add --all. $ git commit f e fix ind

28 Merge: Bringing History together Bring work from another branch into current branch Implemented features, fixed bugs, etc. Updates current branch, not other current other other current

29 Merge Case 1: Ancestor is an ancestor of other branch e

30 Fast-Forward Merge $ git merge e

31 Merge Case 2: No Conflicts f e

32 Merge Automatically Commits $ git merge f e g

33 Merge Case 3: Conflicts Exist $ git merge f e files with conflicts marked ind files that could be merged automatically

34 Merge: Resolve Conflicts $ emacs somefile f e files with conflicts resolved ind

35 Merge with Conflicts: Add $ git add somefile f e ind

36 Merge with Conflicts: Commit $ git commit f e g ind

37 Summary Repository = working tree + store Store contains history History is a DAG of commits References, tags, and Commit/checkout are local operations Former changes store, latter working tree

Git: (Distributed) Version Control

Git: (Distributed) Version Control Computer Science and Engineering College of Engineering The Ohio State University Lecture 6 The Need for Version Control Track evolution of a software artifact Development