Why do wee need a tool for revision control
- Managing a proliferation of versions during development
- Keeping a history of modifications to software
- Maintaining "frozen" versions of released software
- Managing independent development tracks
- Coordinating the activities of multiple developers
- Managing local modifications to code supplied by an outside vendor
Historical Revision Control Tools
- Source Code Control System (SCCS)
- Revision Control System (RCS)
- Concurrent Versions System (CVS)
- Subversion (SVN)
- Mercurial
What is git?
- A revision control system for tracking changes to files and coordinating concurrent updates
- Originally designed and implemented by Linus Torvalds, for Linux
- Distributed - each developer has a complete copy of the revision history
- Supports concurrent development activity using optimistic (non-locking) concurrency control
What can you do with git?
- Retrieve old versions of source code
- Extract change logs that describe development history
- Compute "diffs" showing the difference between versions.
- Automatically revert (undo) changes found to be problematic
- Merge changes made by other developers
The git Development Model
-
Repository: Storage area for commits
- Local: Repo located on your computer
- Remote: Repo located on a server
- Upstream Default repo for fetch and push
-
Working area: Active copy of source tree
- Clean/Dirty: agrees/does not agree with last checkout
-
Commit: Saved snapshot of source tree
- Commit ID: Hexadecimal hash code that uniquely identifies a commit
- Commit message: informative text used to describe a commit
-
Checkout: Update working area from commit
-
Branch: Movable label placed on commit (tracks changes)
- Local: Branch label managed by you
- Remote-tracking: Label that follows branch in remote repo
- Head: Commit on which the branch label is placed
-
Tag: Fixed label placed on commit (Does not move)
-
Push: Update a branch on a remote repo
- Fetch: Download commits from a remote repo
-
Merge: Integrate a commit into the current branch
- Fast-forward: Merge performed simply by moving branch label
-
Index: A list of changed files that have been staged(marked) for commit
- "git add": Mark a file a staged for commit
-
Reset: Unstage files from the index
- Hard reset: Modifies the index and resets files in the working area
Commits
- A commit corresponds to a single version of an entire source ree.
- Each commit contains a commit message that describes the purpose of the commit.
- Each commit refers to one or more parent commits (so that commits frorm a DAG)
- Each commit is uniquely identified by a commit ID (created by hashing content).
- the hash of a commit depends on the hashes of its parents.
- Hashing allows commits to be made independently, without coordination.
Branches
- A branch is a symbolic label that refers to a commit.
- A branch can be checked out into the working area
- Changes made in the working area can be committed to a branch.
- Committing advances the branch label to the new commit.
- Commits on other branches can be merged into the current branch.
Diffs, Mergin, and Conflicts
- Most revision control systems have an underlying concept of a diff (or "delta") to source code.
- Independent diffs can be merged (combined) automatically
- Two diffs on the same base version are independent if they apply to "different parts of the code"
- Conflicting (non-independent) diffs require the developer's intervention to merge.
