Transcript
Git Objektumorientált szoftvertervezés Object-oriented software design Dr. Balázs Simon BME, IIT
Outline Version control Git version control Best practices for using Git
Sources: https://www.atlassian.com/git http://nvie.com/posts/a-successful-git-branching-model/ Ryan Hodson: Ry's Git Tutorial
Dr. Balázs Simon, BME, IIT
2
Version control
Dr. Balázs Simon, BME, IIT
3
Version control Management of changes of a set of files documents, computer programs and other collections of information
Other names: source control, revision control Changes are identified by an identifier called revision or revision number usually a number or a string identifier
A version control system (VCS) allows: revert a set of files or an entire project back to a previous state compare changes over time see who modified the files and what modifications they made recover files which get lost or corrupted Dr. Balázs Simon, BME, IIT
4
Manual version control Before automatic version control systems Simplest form of version control Manually copy files and folders and give them new names Problems: inconsistent revision numbers, especially if the document is shared between people e.g. doc-2016-v12.5-DH-2-LK-3.docx
mislabeling a file or folder forgetting to save an important stage accidentally overwriting the wrong file or folder you will never know if you lost something important
Dr. Balázs Simon, BME, IIT
5
Local version control Store different versions of the files in a database on the local computer Whenever we need an older version we look it up in the database and check it out We only have a single copy at any given time Therefore, we can’t mix up or lose revisions Problem: files cannot be shared with other people
Database Files Dr. Balázs Simon, BME, IIT
Different versions
6
Centralized version control Store different versions of the files in a database on a central server Developers check out files from this central database and save them back over a network Several people can collaborate Central administrative control over who can do what This model has been the standard of version control for a long time (e.g. CVS, SVN) Problems: Central VCS Server the server is a single point of failure if it goes down, nobody can work if the disk gets corrupted, everything is lost (if there were no backups)
conflicting changes have to be manually resolved until then nobody can work
User 3
User 1 Dr. Balázs Simon, BME, IIT
User 2
7
Distributed version control Every developer has a local copy of the entire repository, including the history no single point of failure anymore easy to restore from any local copy
We have a distributed network of repositories although we can have a designated “central” repository for synchronizing between users
Each developer can work in isolation at their own pace store updates locally put off merging conflicts until their convenience
User 2
Efficient management of branches experimenting with different ideas
Development is much faster no need to perform actions over a network Dr. Balázs Simon, BME, IIT
User 1
User 3
8
Git
Dr. Balázs Simon, BME, IIT
9
Git Distributed version control system (DVCS) Written by Linus Torvalds for managing the Linux kernel source Design goals: reliability efficient management of large projects support for distributed development support for non-linear development
Git became stable and very popular over the years Most popular “central” server for remote repositories: GitHub Git is a command line tool but it has graphical wrappers, e.g. TortoiseGit Dr. Balázs Simon, BME, IIT
10
Git concepts Working directory:
current files you see in the file system
Tracked files:
files under version control Git ignores untracked files e.g. don’t track binaries and generated files, since they are very big, they change frequently, and they can always be reproduced by compiling the source
Staged snapshot (index/cache):
set of file paths (not the file contents!) selected for the next commit staging is a preparation for the next commit sometimes we don’t want all the changed files to be included in the next commit: in the staging phase we can select the ones we want or we can select all of them
Committed snapshot:
a recorded staged snapshot with a descriptive message committing puts the files selected in the staged snapshot into the local repository committed snapshots are safe versions of the project, Git will never change them: this is what we want from a version control system
Development branch:
a branch is an independent line of development, a series of committed snapshots contains an experiment of a new idea/bugfix/feature without affecting other branches
Dr. Balázs Simon, BME, IIT
11
Git operations Local computer
commit
add/remove commit all
workspace
Network
staging
push local repository
remote repository
clone/pull fetch reset/checkout/merge/rebase reset/checkout diff HEAD diff Dr. Balázs Simon, BME, IIT
12
Git commands Local computer git add/rm/mv
git commit
git commit -a
workspace
Network
staging
git push local repository
remote repository
git clone/pull git fetch git reset/checkout/merge/rebase
git reset/checkout
git diff HEAD git diff Dr. Balázs Simon, BME, IIT
13
Git repository Creating a local repository:
New empty local repository:
go into the my-repo directory issue the following command: git init this creates a .git hidden directory which contains the local repository
my-repo .git (local repository) my files and folders (workspace)
New empty local bare repository, which can be used as a “central” remote repository by developers: git init --bare
Cloning an existing remote repository as a new local repository: git clone creates a new my-repo directory with the .git hidden folder inside
Check the status of a repository:
git status shows changed and untracked files
View repository history: git log git log --oneline
Dr. Balázs Simon, BME, IIT
14
Configuring git Global user name and e-mail: used for all repositories on the computer as default git config --global user.name “My Name” git config --global user.email “[email protected]”
Repository specific name and e-mail: used for the specific repository only git config user.name “My Name” git config user.email “[email protected]”
Dr. Balázs Simon, BME, IIT
15
Staging Staging is a preparation for the next commit Add a file for staging (also for tracking if it is not yet tracked): git add undo: git reset
Rename a tracked file and add for staging: git mv undo: git mv
Delete a tracked file and add for staging: git rm
undo (be careful with these, you can lose uncommitted changes): git reset -- git checkout --
git add/rm/mv
Local computer
git commit
git commit -a
workspace Dr. Balázs Simon, BME, IIT
staging
Network
git push local repository
remote repository
16
Commit Create a local committed snapshot from the current stage: git commit -m “Commit message”
Commit all modified tracked files (no need for staging): git commit -a -m “Commit message”
A committed snapshot is safe, it will not be changed anymore Local computer git add/rm/mv
git commit
git commit -a
workspace
Dr. Balázs Simon, BME, IIT
staging
Network
git push local repository
remote repository
17
Push Push all local commits to the remote repository: git push pushes the specific branch
git push --all
pushes all branches
the remote is “origin” if the repository was created with clone the remote can be a URL of a remote repository Never push to other developers’ local repositories directly! Only push to bare (“central”) repositories, which don’t have working directories!
Push will fail if the remote branch has changed since the last push: at first we need to merge remote and local changes to do that we need to pull/fetch the remote changes to our local computer
Local computer git add/rm/mv
git commit
git commit -a
workspace Dr. Balázs Simon, BME, IIT
staging
Network
git push local repository
remote repository
18
Fetch Downloads all commits and files from the remote repository git fetch fetches all branches
git fetch fetches only the specified branch
Gives access to the entire branch structure of another repository Fetch will not overwrite our local branches, it only creates remote branches (branches prefixed by their remote names) e.g. origin/master, origin/some-nice-feature, origin/v1 etc.
The downloaded remote branches can be listed with: git branch -r
Local computer Network workspace
staging
local repository
remote repository
git pull
git merge/rebase
git fetch
19
Merge and Rebase When two branches diverge from each other, then we eventually need to bring them together
e.g. the remote branch and the local branch both evolved parallel to each other, and we need to push our local branch to the remote repository
Merge: add changes from another branch to the current branch git merge origin/master e.g. add everyone else’s changes to my changes
Rebase: add changes from our current branch to the other branch git rebase origin/master e.g. add my changes to everyone else’s changes
Both merge and rebase create a new commit:
this commit can now be pushed to the remote repository both branches point to this new commit
Local computer Network
workspace
staging
local repository
remote repository
git pull
git merge/rebase
git fetch
20
Pull Combines fetch and merge/rebase in a single command Fetch+merge for the current branch: git pull same as: git fetch git merge origin/
Fetch+rebase for the current: git
pull --rebase
same as: git fetch git rebase origin/ Local computer Network workspace
staging
local repository
remote repository
git pull
git merge/rebase
git fetch
21
Branch A branch is an independent line of development, a series of committed snapshots snapshots/revisions are identified by their SHA-1 checksums the currently checked-out snapshot is called HEAD
A branch contains an experiment of a new idea/bugfix/feature without affecting other branches List all branches: git branch
Create a new branch (does not switch to the branch!): git branch
Switch to a branch:
git checkout
Branches are lightweight, they are only a series of committed snapshots forking happens only when we commit a new snapshot to the new branch
Dr. Balázs Simon, BME, IIT
master
22
Branching examples Initial state: a
master b
c
d
a
b
c
d
The working directory contains revision “e”. We are at the HEAD of the “master” branch.
e HEAD
older revisions After the following command: git checkout d
master e
After the following commands: git branch hello git checkout hello master a
b
c
d hello
Dr. Balázs Simon, BME, IIT
current branch
e
The working directory contains revision “d”. Since no branch points to the HEAD, we are on no branch, we cannot commit!
We are at the HEAD of the “hello” branch. A new commit will fork from revision “d”.
23
Branching examples From the previous slide: a
master b
c
d
e
hello
After some changes and the following command: git commit -a “Changes” master a
b
c
d
e f
hello
Dr. Balázs Simon, BME, IIT
24
Branching examples After some other changes and commits (even the master branch can evolve): master a
b
c
d
e
i
f
g
h hello
After we are finished with the hello feature, we can merge it to the master branch: git checkout master git merge hello master a
b
c
d
e
i
f
g
j h hello
Dr. Balázs Simon, BME, IIT
25
Branching examples From the previous slide: master a
b
c
d
e
i
f
g
j h hello
We can delete the hello branch if we don’t need it anymore. Its commits are available from the master branch: git branch -d hello master a
Dr. Balázs Simon, BME, IIT
b
c
d
e
i
f
g
j h
26
Fast-forward merge Sometimes one of the branches does not evolve: this is common when the other branch is short-lived master
Initial state: a
b
c
d
After the following commands: git branch hello git checkout hello a
b
e
master c
d
e hello
After some changes and the following command: git commit -a “Changes” master a
b
c
d
Now there is no actual merge needed, the master branch can be fast-forwarded to revision “h”.
e f
Dr. Balázs Simon, BME, IIT
g
h hello
27
Fast-forward merge From the previous slide: Now there is no actual merge needed, the master branch can be fast-forwarded to revision “h”.
master a
b
c
d
e f
g
h hello
After merging (fast-forward): git checkout master git merge hello git branch -d hello a
master b
c
d
e
f
g
h
There cannot be any merge conflicts on fast-forward!
Dr. Balázs Simon, BME, IIT
28
Rebase master
Initial state: a
b
c
d
e
i
f
g
h
hello
Rebase: git checkout hello git rebase master a
b
master c
d
e
i
Rebase rewrites the project history with brand new commits! Results in a cleaner project history, but we lose safety and traceability.
f*
g*
h* hello
Be careful: never rebase public branches (e.g. master) on top of your private branch! It changes the history of the public branch, and other developers will be confused. Dr. Balázs Simon, BME, IIT
29
Reset on commits Reset can be used on commits git reset moves the tip of the branch to another commit can be used to remove commits
Be very careful with this! Use it only to undo changes that haven’t been shared with anyone else! master a
b
c
Reset: git reset d a Dr. Balázs Simon, BME, IIT
b
d
e
master c
d
dangling commit, will be garbage collected by Git e
30
Reset on files Used to undo files in the working directory and to undo staging (index) Hard reset: git reset --hard HEAD moves HEAD, resets working directory and index all your work is lost since the last commit
Mixed reset (default):
git reset --mixed HEAD git reset HEAD moves HEAD, resets the index, but not the working directory your work is not lost, but will not be committed
Soft reset (rarely used):
git reset --soft HEAD moves HEAD, doesn’t change the index or working directory use this when you want to move to another commit and patch things up without “losing your place”
If you use a specific instead of HEAD, it will reset only that file Dr. Balázs Simon, BME, IIT
31
Tags Tags are used to mark specific points (commits) in the project history e.g. release points (v1.0, etc.)
Listing tags: git tag
Lightweight tag (just a marker): git tag
Annotated tag (more info, like a branch that does not change): git tag -a -m
Tagging an earlier commit: git tag -a
Tags are not pushed automatically. Pushing them explicitly: git push --tags Dr. Balázs Simon, BME, IIT
32
Stash Often you are in the middle of something, the work is in a half-done state You need to switch to another branch for a bit to work on something else But you don’t want to commit half-done work Stash can save the current state of a dirty working directory and the index: git stash
After you are done and want to restore: git stash pop
List current stashes: git stash list
Apply a specific stash:
git stash apply git stash apply --index
Drop a stash:
git stash drop
Dr. Balázs Simon, BME, IIT
33
Pull request Used in public collaboration, e.g. GitHub you fork someone else’s repository to develop a new feature in your own repository when you are ready with the feature, you notify the original developer with a pull request so that he can include (pull) your changes to his own repository
Once a pull request is opened, you can discuss and review the potential changes with collaborators and add followup commits before the changes are merged into the repository
Dr. Balázs Simon, BME, IIT
34
Best practices for using Git
Dr. Balázs Simon, BME, IIT
35
Git best practices Do: commit related changes commit often write useful commit messages test before you commit use branches agree on a workflow
Don’t: commit unrelated changes e.g. fixing two bugs at once
use Git as a backup system don’t commit half-done work that does not compile commits should be semantically meaningful
change published history e.g. rebase a public branch Dr. Balázs Simon, BME, IIT
36
Git branching model Vincent Driessen: http://nvie.com/posts/a-successful-git-branching-model/
(or this can be the master)
Dr. Balázs Simon, BME, IIT
(and this can be the release)
37
Git branching model
Dr. Balázs Simon, BME, IIT
38
Git branching model
Dr. Balázs Simon, BME, IIT
39
