CS代写 Distributed Version Control

Distributed Version Control
Computer Science and Engineering  College of Engineering  The Ohio State University

Sarah’s Repository

Copyright By PowCoder代写 加微信 powcoder

Science and Engineering  The Ohio State University

And Matt’s Repository
Science and Engineering  The Ohio State University

Some Shared History
Science and Engineering  The Ohio State University

Fetch: Remote Store -> Local
sarah$ git fetch mt
Science and Engineering  The Ohio State University
working tree unaffected!
new changesets added to store
remote branch

Remote Repository Unchanged
Computer Science and Engineering  The Ohio State University

Workflow: Merge After Fetch
sarah$ git merge mt/main
Computer Science and Engineering  The Ohio State University

Remote Repository Unchanged
Computer Science and Engineering  The Ohio State University

What Does “D” Stand For?
Computer Science and Engineering  The Ohio State University
Distributed version control Multiple people, distributed across network
Each person has their own repository!
Everyone has their own store (history)! Big difference with older VCS (eg SVN)
Units of data movement: changeset Communication between teammates is to bring stores in sync
Basic operators: fetch and push

Workflow: Merge After Fetch
sarah$ git merge mt/main
Computer Science and Engineering  The Ohio State University

Remote Repository Unchanged
Computer Science and Engineering  The Ohio State University

View of DAG with All Branches
Computer Science and Engineering  The Ohio State University
$ git log –oneline –graph –decorate –all
* 1618849 (HEAD-> main, origin/main) clean up css
* d579fa2 (alert) merge in improvements from master
| * 0f10869 replace image-url helper in css
* | b595b10 (origin/alert) 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

Sarah and Matt’s Repositories
Computer Science and Engineering  The Ohio State University
EAD mt/main main

Some Shared History
Computer Science and Engineering  The Ohio State University
EAD mt/main main

Your Turn: Fetch
matt$ git fetch sr
Science and Engineering  The Ohio State University
EAD mt/main main

Fetch: After
matt$ git fetch sr
Computer Science and Engineering  The Ohio State University
main sr/main

Your Turn: Merge
matt$ git merge sr/main
Computer Science and Engineering  The Ohio State University
main sr/main

Merge: After
matt$ git merge sr/main
Computer Science and Engineering  The Ohio State University
main sr/main

Pull: Fetch then Merge
Computer Science and Engineering  The Ohio State University
A “pull” combines both fetch & merge
matt$ git pull sr
Advice: Prefer explicit fetch, merge After fetch, examine new work
$ git log –all #see commit messages $ git checkout #see work
$ git diff #compare
Then merge
Easier to adopt more complex workflows (e.g., rebasing instead of merging)

Push: Local Store -> Remote
Computer Science and Engineering  The Ohio State University
Push sends local commits to remote store Usually push one branch (at a time)
sarah$ git push mt fix
Advances Matt’s fix branch
Advances Sarah’s mt/fix remote branch Requires:
1. Matt’s fix branch must not be his HEAD
2. Matt’s fix branch must be ancestor of Sarah’s
Common practices:
1. Only push to bare repositories (bare means no
2. working tree, ie no HEAD)
3. Get remote store’s branch into local DAG (ie fetch,
merge, commit) before pushing

Remote’s Branch is Ancestor
Science and Engineering  The Ohio State University
HEAD mt/fix fix

Push: Local Store -> Remote
sarah$ git push mt fix
Computer Science and Engineering  The Ohio State University
HEAD mt/fix fix

Push: After
sarah$ git push mt fix
Computer Science and Engineering  The Ohio State University
fix mt/fix
working tree unaffected!

Commit/Checkout vs Push/ Science and Engineering  The Ohio State University

Common Topology: Star
Computer Science and Engineering  The Ohio State University
n-person team has n+1 repositories
1 shared central repository (bare!) 1 local repository / developer
Each developer clones central
repository
Cloning creates a remote called “origin” Default source/destination for fetch/push
Variations for central repository:
Everyone can read and write (ie push) Everyone can read, but only 1 person can write (pulling and merging)

Common Topology: Star
Computer Science and Engineering  The Ohio State University
Source: http://nvie.com/posts/a-successful-git-branching-model/
Bare repository (no working tree)

Computer Science and Engineering  The Ohio State University
Push/fetch to share your store with remote repositories
Neither working tree is affected
Branches in history are easy to form
Committing when HEAD is not a leaf Fetching work based on earlier commit
Team coordination
One single, central repo
Every developer pushes/fetches from their (local) repo to this central (remote) repo

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com