Git. Objektumorientált szoftvertervezés Object-oriented software design. Dr. Balázs Simon BME, IIT

Transcription

1 Git Objektumorientált szoftvertervezés Object-oriented software design Dr. Balázs Simon BME, IIT

2 Outline Version control Git version control Best practices for using Git Sources: Ryan Hodson: Ry's Git Tutorial Dr. Balázs Simon, BME, IIT 2

3 Version control Dr. Balázs Simon, BME, IIT 3

4 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

5 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

6 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 Different versions Dr. Balázs Simon, BME, IIT 6

7 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 1 Dr. Balázs Simon, BME, IIT 7 User 2 User 3

8 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 Efficient management of branches experimenting with different ideas Development is much faster no need to perform actions over a network User 1 User 2 User 3 Dr. Balázs Simon, BME, IIT 8

9 Git Dr. Balázs Simon, BME, IIT 9

10 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

11 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

12 Git operations Local computer Network add/remove commit commit all push workspace staging local repository remote repository clone/pull reset/checkout/merge/rebase fetch reset/checkout diff diff HEAD Dr. Balázs Simon, BME, IIT 12

13 Git commands Local computer Network git add/rm/mv git commit git commit -a git push workspace staging local repository remote repository git clone/pull git fetch git reset/checkout/merge/rebase <commit> git reset/checkout <file> git diff git diff HEAD Dr. Balázs Simon, BME, IIT 13

14 Git repository Creating a local repository: my-repo New empty local repository: go into the my-repo directory.git (local repository) issue the following command: git init this creates a.git hidden directory which contains the local repository 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 <url> 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 my files and folders (workspace) Dr. Balázs Simon, BME, IIT 14

15 Configuring git Global user name and used for all repositories on the computer as default git config --global user.name My Name git config --global user. Repository specific name and used for the specific repository only git config user.name My Name git config user. Dr. Balázs Simon, BME, IIT 15

16 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 <filename> undo: git reset <filename> Rename a tracked file and add for staging: git mv <from> <to> undo: git mv <to> <from> Delete a tracked file and add for staging: git rm <filename> undo (be careful with these, you can lose uncommitted changes): git reset -- <filename> git checkout -- <filename> git add/rm/mv git commit Local computer Network git commit -a git push workspace staging local repository remote repository Dr. Balázs Simon, BME, IIT 16

17 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 Network git add/rm/mv git commit git commit -a git push workspace staging local repository remote repository Dr. Balázs Simon, BME, IIT 17

18 Push Push all local commits to the remote repository: git push <remote> <branch> pushes the specific branch git push <remote> --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 git add/rm/mv git commit Local computer Network git commit -a git push workspace staging local repository remote repository Dr. Balázs Simon, BME, IIT 18

19 Fetch Downloads all commits and files from the remote repository git fetch <remote> fetches all branches git fetch <remote> <branch> 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 <commit> git fetch 19

20 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 <commit> git fetch 20

21 Pull Combines fetch and merge/rebase in a single command Fetch+merge for the current branch: git pull <remote> same as: git fetch <remote> git merge origin/<current-branch> Fetch+rebase for the current: git pull --rebase <remote> same as: git fetch <remote> git rebase origin/<current-branch> Local computer Network workspace staging local repository remote repository git pull git merge/rebase <commit> git fetch 21

22 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 <branch-name> Switch to a branch: git checkout <branch-name> Branches are lightweight, they are only a series of committed snapshots master forking happens only when we commit a new snapshot to the new branch Dr. Balázs Simon, BME, IIT 22

23 Branching examples Initial state: master a b c d e older revisions HEAD current branch The working directory contains revision e. We are at the HEAD of the master branch. After the following command: git checkout d a b c d master e The working directory contains revision d. Since no branch points to the HEAD, we are on no branch, we cannot commit! After the following commands: git branch hello git checkout hello a b c d master e We are at the HEAD of the hello branch. A new commit will fork from revision d. hello Dr. Balázs Simon, BME, IIT 23

24 Branching examples From the previous slide: master a 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

25 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 j f g h hello Dr. Balázs Simon, BME, IIT 25

26 Branching examples From the previous slide: master a b c d e i j f g 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 b c d e i j f g h Dr. Balázs Simon, BME, IIT 26

27 Fast-forward merge Sometimes one of the branches does not evolve: this is common when the other branch is short-lived Initial state: master a b c d e After the following commands: git branch hello git checkout hello master a b c d e hello After some changes and the following command: git commit -a Changes master a b c d e f Now there is no actual merge needed, the master branch can be fast-forwarded to revision h. g h hello Dr. Balázs Simon, BME, IIT 27

28 Fast-forward merge From the previous slide: a b c d master e Now there is no actual merge needed, the master branch can be fast-forwarded to revision h. f g h hello After merging (fast-forward): git checkout master git merge hello git branch -d hello master a b c d e f g h There cannot be any merge conflicts on fast-forward! Dr. Balázs Simon, BME, IIT 28

29 Rebase Initial state: master a b c d e i f g h hello Rebase: git checkout hello git rebase master master a b 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

30 Reset on commits Reset can be used on commits git reset <commit-checksum> 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 d e Reset: git reset d a b c master d e dangling commit, will be garbage collected by Git Dr. Balázs Simon, BME, IIT 30

31 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 <filename> instead of HEAD, it will reset only that file Dr. Balázs Simon, BME, IIT 31

32 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 <tag-name> Annotated tag (more info, like a branch that does not change): git tag -a <tag-name> -m <message> Tagging an earlier commit: git tag -a <tag-name> <commit-checksum> Tags are not pushed automatically. Pushing them explicitly: git push <remote> --tags Dr. Balázs Simon, BME, IIT 32

33 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 <stash-id> git stash apply <stash-id> --index Drop a stash: git stash drop <stash-id> Dr. Balázs Simon, BME, IIT 33

34 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

35 Best practices for using Git Dr. Balázs Simon, BME, IIT 35

36 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

37 Git branching model Vincent Driessen: (or this can be the master) (and this can be the release) Dr. Balázs Simon, BME, IIT 37

38 Git branching model Dr. Balázs Simon, BME, IIT 38

39 Git branching model Dr. Balázs Simon, BME, IIT 39