|
 |
|
Lecture 15 — git
|
|
|
|
|
source control concepts
|
|
|
 |
|
source control is a way to organize and coordinate development of a set of source files
|
|
|
|
|
repository (repo for short)
|
|
|
|
|
an instance of the stored files
|
|
|
|
|
a log of all the changes to the files
|
|
|
|
|
potentially other metadata
|
|
|
|
|
changeset
|
|
|
|
|
updates to files in the repo are represented as deltas — the set of changes that were made
|
|
|
|
|
the user controls when a set of changes officially becomes part of the repo
|
|
|
|
|
at some point the user will commit changes, which incorporates them into the repo’s log
|
|
|
|
|
only committed changes can be shared with other users
|
|
|
|
|
distributed vs centralized
|
|
|
|
|
centralized has a single authoritative repo, all changes go through this repo
|
|
|
|
|
decentralized treats all repos as equal — more flexibility, but less structure
|
|
|
|
|
faster because there’s no need to check with a central server
|
|
|
|
|
can use decentralized as if it were centralized (what you will do for hw5)
|
|
|
|
|
graph structure
|
|
|
|
|
history of a repo can be represented as a directed acyclic graph (DAG)
|
|
|
|
|
each commit adds a node to the graph
|
|
|
|
|
each commit must be applied to some existing node
|
|
|
|
|
branches allow for parallel development
|
|
|
|
|
new features, experiments, specialized version
|
|
|
|
|
a merge occurs when multiple nodes converge
|
|
|
|
|
multiple users have each made changes and now they must be combined
|
|
|
|
|
GitLab
|
|
|
|
|
We’ll be using CSE’s GitLab
|
|
|
|
|
set up ssh key for each machine you want to connect
|
|
|
|
|
git commands
|
|
|
|
|
git clone
|
|
|
|
|
set up your own copy of an existing repo
|
|
|
|
|
git init to initialize a new repo in an existing folder
|
|
|
|
|
git status
|
|
|
|
|
display the status of your local repo
|
|
|
|
|
files that have been changed, added, removed
|
|
|
|
|
files that are not currently part of the repo
|
|
|
|
|
git diff
|
|
|
|
|
display what changes have been made
|
|
|
|
|
git checkout
|
|
|
|
|
git checkout -- FILENAME to throw away local changes
|
|
|
|
|
omit FILENAME to throw away all local changes
|
|
|
|
|
git add
|
|
|
|
|
git treats changes as being in one of three states
|
|
|
|
|
(1) not staged for commit
|
|
|
|
|
(2) staged for commit
|
|
|
|
|
(3) committed
|
|
|
|
|
git add FILENAME moves changes to FILENAME from (1) to (2), staging them for commit
|
|
|
|
|
this allows you to commit only some of the changes you have made
|
|
|
|
|
git commit
|
|
|
|
|
git commit -m “commit message” makes all staged changes officially part of your repo
|
|
|
|
|
git push
|
|
|
|
|
sends your commits to another repo
|
|
|
|
|
your repo must be up to date, so git pull beforehand
|
|
|
|
|
git log
|
|
|
|
|
view the history of the repo
|
|
|
|
|
git pull
|
|
|
|
|
fetches updates from another repo and merges them into your local repo
|
|
|
|
|
a merge conflict might occur if you and someone else have made changes in the same part of a file
|
|
|
|
|
conflicts will be shown in the conflicted files themselves with
<<<<<<< HEAD
…
your version here
…
=======
…
their version here
…
>>>>>>> master
|
|
|
|
|
you must manually resolve all conflicts and then add and commit the merged files
|
|
|
|
|
hw5
|
|
|
|
|
memory management (Friday’s lecture)
|
|
|
|
|
required to do it in a team of 2
|
|
|
|
|
midterms
|
|
|
|
|
mean and median: 44 of 72
|
|
|
|
|
standard deviation: 10
|
|
|