Version control Flashcards
(37 cards)
What is version control?
A system for managing changes to documents, programs, web pages
Why do we need version control?
Keep track of a revision history/versions of a document, enable users to collaborate on a collection of documents
Other version control systems other than Git?
rcs, cvs, subversion, mercurial
What are the 3 types of version control?
Local, centralized, distributed
They differ in how the version database is stored.
Local vs centralized?
For local, there is no server involved. The version database is stored locally. Only the local computer can checkout the file.
For centralized, there is a central server and each computer checks out the file from this server to get a local copy of the file on their own computer.
Centralized vs distributed?
For centralized, there is one server that saves the version database, no users have the database on their computer.
For distributed, there is a server with the version database and each user has their own version database on their computer.
Which VCS stores differences?
mercurial
Which VCS stores snapshots?
git
Differences vs snapshots?
Differences is when a file is changed, the VCS only saves the changes as a new version (the difference between the previous version to current). If one file among all files is not changed in a version, the file is not updated. For example, if file A is changed, version 1 is only the changes in file A.
Snapshots is when a file is changed, all files are saved as a new version the way they are. For example, if file A is changed, version 1 becomes file A1, B, C.
Why is using differences inefficient?
Because every time we want the latest version of a file, we need to start from the initial file and apply all the changes along the versions.
Describe the common git workflow.
git init/clone, git add, git commit, git push, git pull (git fetch + git merge)
Does git use a three-stage architecture?
Yes
Describe the three-stage architecture of Git.
The 3 stages are: working directory, staging area, local repository (.git repository)
Working directory is where the actual project files are located. Any changes made to files here are untracked. To get to staging area, we use “git add”.
Staging area is an intermediate step between the working directory and .git repo. We basically store everything we want to commit in the next commit here. To get to the .git repo, use “git commit”.
.git repo is like a container for Git’s VCS. It stores committed snapshots, the project’s history, and facilitate with Git operation. To move the files to the remote repo, use “git push”.
Commands to interact with the remote repo: git pull, git push, git clone, git fetch
Relationship between blobs, trees, and commits?
Each commit has a unique commit id and a tree id of the tree it belongs to. A tree stores its own id and blobs ids. A blob is just an object type used to store file contents and each of them has an id. Can think of each blob as a file in our repo.
Is a commit a snapshot of the state of the project?
Yes
When does the blob id change?
When the file contents change (even by 1 byte). Each blob id refers to a specific version of a file.
What algorithm is used to make commit ids?
SHA-1
How many percent of a hash will change when you change a file?
50%
How many digits of the 40 digits hash does git use?
First 8 digits
What is git tag?
“git tag NAME” is a command we can use to give a name to a certain commit (kind of like a pointer)
Where does HEAD always point to?
HEAD always points to the latest commit of the current branch. e.g. HEAD points to master, which is a branch, and master points to the latest commit id.
When there is a branch, we can imagine this branch has a pointer with its name and it points to the latest commit. Then HEAD points to the branch pointer.
Should we touch the master branch? What should it be used for?
No. Only well-tested, stable commits. Usually only when we need to release to customers.
Other than the master branch, what other branches do we usually use?
1) Development branch
2) Feature branches to test out things before merging into development
3) Release branches to store versions ready to be released
4) Hotfixes include bugs fixed. When a bug is detected and fixed, the development commits do not have this fix, so remember to add it to the dev branch. Then release a new version to customers via the master branch. Next time, when a version is added to the release branch, this bug fixed will be included.
In a commit message, should the subject line be attached to the body?
No, there should be a blank line
