Git Basics. Christian Hanser. Institute for Applied Information Processing and Communications Graz University of Technology. 6.

Transcription

1 Git Basics Christian Hanser Institute for Applied Information Processing and Communications Graz University of Technology 6. March 2013 Christian Hanser 6. March 2013 Seite 1/39

2 Outline Learning Targets Version Control Systems Git Basics Philosophy of Git Working with Git Conclusions Christian Hanser 6. March 2013 Seite 2/39

3 Learning Targets Being able to describe Git s principles, and being able to use Git in a basic way Christian Hanser 6. March 2013 Seite 3/39

4 Version Control Systems Goals keeping track of file revisions, and easing joint work of several parties on the same project For instance CVS, Mercurial, SVN, Git,... Christian Hanser 6. March 2013 Seite 4/39

5 Version Control Systems (cont.) Terminology a commit holds changes to a set of files in the working directory at some point in time a repository is an ordered tree-like structure of commits. It holds the current and the historical data of all files ever version-controlled in the working directory a branch is a branch of the repository tree, representing a development strand (e.g. for the development of a new feature) Christian Hanser 6. March 2013 Seite 5/39

6 Example of a Repository Tree C experimental init... master B develop Branches: master, develop, experimental Christian Hanser 6. March 2013 Seite 6/39

7 Version Control Systems (cont.) Terminology (cont.) working directory is the user s current view on the files in the repository a merge denotes the application of two different sets of changes to a set of files, e.g., by combining two branches head is a pointer to the commit the user is currently working on a tag is a label on a commit Christian Hanser 6. March 2013 Seite 7/39

8 Example of a Repository Tree (cont.) C experimental init... master, HEAD B develop Current branch: master Christian Hanser 6. March 2013 Seite 8/39

9 Outline Learning Targets Version Control Systems Git Basics Philosophy of Git Working with Git Conclusions Christian Hanser 6. March 2013 Seite 9/39

10 Philosophy of Git Git is a high-level mini-filesystem, with remote synchronization capabilities, and some other nice specialties which is well-suited for version-control. Christian Hanser 6. March 2013 Seite 10/39

11 Philosophy of Git (cont.) Advantages of Git s approach: flexibility, little overhead (esp. no network overhead), no restrictions if server is down, and repository manipulations can be done very quickly (as performed locally) Christian Hanser 6. March 2013 Seite 11/39

12 Philosophy of Git (cont.) everything (files/commits/trees) is a data object every data object is identified with its SHA-1 hash integrity, all changes are detectable Christian Hanser 6. March 2013 Seite 12/39

13 Outline Learning Targets Version Control Systems Git Basics Philosophy of Git Working with Git Conclusions Christian Hanser 6. March 2013 Seite 13/39

14 Example of a Git Repository Tree /test_git (master)$ git gr 1 * a5bcc47 (HEAD, master) Merge branch develop \ * df6b942 (develop) function headers * d basic functionality / * 4da52aa added main() * 58863bd added header file * e244fda init df6b942 (develop) e244fda 58863bd 4da52aa d a5bcc47 (master) We can see that every node is identified by a hash value! 1 cf. Appendix for git gr Christian Hanser 6. March 2013 Seite 14/39

15 Git s Three States Areas, where files reside: working directory: holds current source (with latest, untracked changes) staging area: reservoir of changes for next commit (allows selecting changes for next commit) repository: holds the commits; safe area List changes in working directory and staging area with /test_git (experimental)$ git status Christian Hanser 6. March 2013 Seite 15/39

16 Git s Three States (cont.) Figure: Git s Three States (Source: [1]) Christian Hanser 6. March 2013 Seite 16/39

17 Committing Changes Now, suppose we are working in the branch experimental: init... master B experimental and want to commit some untracked changes (and files): /test_git (experimental)$ git status # On branch experimental # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: src/main.h # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # src/main.c Christian Hanser 6. March 2013 Seite 17/39

18 Committing Changes (cont.) To do so, we collect the changes for the next commit, by adding them to the staging area: /test_git (experimental)$ git add *.c *.h yielding the following status: /test_git (experimental)$ git status # On branch experimental # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: src/main.h # new file: src/main.c Christian Hanser 6. March 2013 Seite 18/39

19 Committing Changes (cont.) Now we can commit the collected changes followingly: /test_git (experimental)$ git commit -m "bugfix" changing the repository tree from init... master A experimental (B) to init... master A B experimental Christian Hanser 6. March 2013 Seite 19/39

20 Unstaging Changes Now, suppose we are given the following status: /test_git (experimental)$ git status # On branch experimental # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: src/main.h # new file: src/main.c but only wanted (for whatever reason) to commit the first file. Christian Hanser 6. March 2013 Seite 20/39

21 Unstaging Changes (cont.) To do so we can unstage the second file: /test_git (experimental)$ git reset src/main.c /test_git (experimental)$ git status # On branch experimental # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: src/main.h # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # src/main.c So far, no changes are lost! Christian Hanser 6. March 2013 Seite 21/39

22 Reverting Changes Now, suppose that we would like to undo the changes in main.h. First, we unstage it: /test_git (experimental)$ git reset src/main.h /test_git (experimental)$ git status # On branch experimental # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: src/main.h # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # src/main.c So far, no changes are lost! Christian Hanser 6. March 2013 Seite 22/39

23 Reverting Changes (cont.) We undo the changes in main.h by checking it out from the repository: /test_git (experimental)$ git checkout src/main.h giving the following status: /test_git (experimental)$ git status # On branch experimental # Untracked files: # (use "git add <file>..." to include in what will be committed) # # src/main.c Christian Hanser 6. March 2013 Seite 23/39

24 Branching A new branch (atop of master) can be created by: /test_git (master)$ git branch develop... master, develop The new branch can then be checked out via: /test_git (master)$ git checkout develop Christian Hanser 6. March 2013 Seite 24/39

25 Branching (cont.) Git also allows us to check out a specific commit, e.g., the commit with hash f75f00d: /test_git (master)$ git checkout f75f00d... f75f00d... master and creating a new branch out of it: /test_git (master)$ git branch new branch... new branch (f75f00d)... master Christian Hanser 6. March 2013 Seite 25/39

26 Merging Branches It is best practice to create short-living local branches for new features. For instance, one could create a branch experimental for the implementation of an experimental feature: # creates a new branch and checks it out /test_git (develop)$ git branch experimental... master develop, experimental (A) commit changes to it:... master develop (A) experimental Christian Hanser 6. March 2013 Seite 26/39

27 Merging Branches (cont.) and at a latter point of time, merge experimental back into develop: # merges branches /test_git (develop)$ git merge experimental If there are no new overlapping changes, Git can auto-merge. Otherwise, we may get a conflict: /test_git (develop)$ git status # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: src/main.c which must be resolved using an editor. Christian Hanser 6. March 2013 Seite 27/39

28 Merging Branches (cont.) Merge conflicts look the same as in SVN: <<<<<<< HEAD: src/main.c char* buffer = malloc(136 * sizeof(char)); ======= char* buffer = malloc(140 * sizeof(char)); >>>>>>> experimental: src/main.c The latter is what we need, so we delete the marked lines. At last, we add and commit to finalize the merge. Christian Hanser 6. March 2013 Seite 28/39

29 Deleting Branches After completing the experimental feature and merging it back into develop, we can delete the experimental branch by: /test_git (develop)$ git branch -d experimental Christian Hanser 6. March 2013 Seite 29/39

30 Tagging Commits Tagging allows us to label commits, which is useful to mark releases, for instance. Usage We can tag a commit using: /test_git (master)$ git tag v5.0 commit-hash As with branches, tags can be checked out: /test_git (master)$ git checkout v5.0 Christian Hanser 6. March 2013 Seite 30/39

31 Rebasing Operation on the commit tree that redefines root nodes of subtrees. Alternative to merge, but not always applicable. Attention On rebasing all subtree commit hashes change, making the repository incompatible to local repositories of others. During a rebase merge conflicts can occur. Christian Hanser 6. March 2013 Seite 31/39

32 Rebasing (cont.) Suppose we have merged experimental into the local branch develop, while a team-member has pushed changes to origin/develop. origin/develop master... A (common base) develop Rebase makes it easy to combine remote with local changes: /test_git (develop)$ git pull --rebase This way, our changes will be placed atop of remote changes: master... A origin/develop develop Christian Hanser 6. March 2013 Seite 32/39

33 Rebasing (cont.) Suppose we are working on branch experimental. In between, we ve appended some bugfixes to develop. C experimental master... A (common base) B develop In order to make these changes available to the experimental branch, we can rebase it onto develop: /test_git (develop)$ git rebase develop experimental master... A B develop C experimental Christian Hanser 6. March 2013 Seite 33/39

34 Rebasing (cont.) We are given the following scenario: master A B develop (C) D experimental (E) Instead of merging experimental into develop, we can also rebase develop onto experimental: /test_git (develop)$ git rebase experimental develop master A B C D experimental, develop (E) Advantage: the whole history is being preserved. Christian Hanser 6. March 2013 Seite 34/39

35 Merging vs. Rebasing When working locally, merges can (mostly) be replaced by more sophisticated rebases. Nevertheless, in (most) situations involving remote branches, merging must be used! Note: non-fast-forward merges also preserve the history, use: git merge --no-ff Christian Hanser 6. March 2013 Seite 35/39

36 Interaction with Remote Repositories Only three ways of remote interaction: Cloning a remote repository: git clone user@github.com:repo.git Fetching changes from a remote repository: git fetch (leaves the local HEAD untouched) git pull (fetch and merge remote changes into the local repository) Submitting changes to a remote repository: git push Christian Hanser 6. March 2013 Seite 36/39

37 Conclusions We have seen Git s differences to conventional VCSs, that Git is a very flexible and reliable, how to synchronize with remote repositories, the benefits of branching, and basic operations, such as commit, merging and rebasing. Christian Hanser 6. March 2013 Seite 37/39

38 Literature Scott Chacon Pro Git. apress, Christian Hanser 6. March 2013 Seite 38/39

39 Outline Appendix Additional Material Christian Hanser 6. March 2013 Seite 1/8

40 Pushing Branches In case we want to share branches with others or simply want to create a backup we can push it to the server: /test_git (develop)$ git push origin branch If it is deployed, we can also remove it from the remote repository: /test_git (develop)$ git push origin :experimental Christian Hanser 6. March 2013 Seite 2/8

41 Amendments to Previous Commits Now, suppose that we forgot to add some changes to main.c, we can amend them by /test_git (experimental)$ git add main.c /test_git (experimental)$ git commit --amend Amendments change the hash of the previous commit. Unless we have already pushed it, we can still amend them. Christian Hanser 6. March 2013 Seite 3/8

42 Stashing Changes Git allows stashing uncommitted changes, i.e. it commits changes to an implicit, internal branch. This is useful to save changes temporarily. Suppose, we want to stash changes in branch develop and apply them to experimental: # stash uncommitted changes /test_git (develop)$ git stash # switch the branch /test_git (develop)$ git checkout experimental # apply the changes to experimental /test_git (experimental)$ git stash apply Christian Hanser 6. March 2013 Seite 4/8

43 More Commands Create a new (local) Git repository in a folder: git init List Git-controlled files: git ls Pick a certain commit: git cherry-pick Show diffs: git diff commit1-hash commit2-hash Show detailed log: git log Show changes: git whatchanged Interactive rebasing/history rewriting: git rebase -i commit-hashˆ Use binary search to find bugs: git bisect Christian Hanser 6. March 2013 Seite 5/8

44 SVN vs. Git or How not to use Git A typical, sloppy SVN-style workflow would be for instance: # merge latest changes from remote repository /src/$ git pull # edit some files... # again, merge latest changes from remote repository /src/$ git pull # add all changes to the next commit /src/$ git add -A # commit the above changes /src/$ git commit -m "backup to not lose the latest changes: code optimizations, comments, bugfixes, and other unsorted/unrelated crap" # submit the changes to the remove repository /src/$ git push In contrast to SVN and the like, Git induces us to organize our commits. Christian Hanser 6. March 2013 Seite 6/8

45 .gitignore Similar to SVN, we can add.gitignore files, in order to hide files in status messages: /test_git (master)$ cat.gitignore.gitignore.classpath.project.settings/ bin/ *.txt Christian Hanser 6. March 2013 Seite 7/8

46 .gitconfig Put this in your /.gitconfig 2 file to enable useful aliases: [user] name = Your Name = yourname@student.tugraz.at [alias] st = status ci = commit co = checkout br = branch gr = "!git --no-pager log -n 20 --graph --full-history\ --all --color --pretty=tformat:\ %x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s%x20%x1b[33m(%an %ar)%x1b[0m " [color] ui = auto Use git gr to print logs: * a85eac7 (HEAD, experimental) initial commit (Christian Hanser) * 7297cd1 (develop) fixed possible bug in lib.c (Christian Hanser) * 03e4d45 added lib.c (Christian Hanser) / * 06a7bcf hello world now working (Christian Hanser)... 2 Windows: C:\Document and Settings\yourusername\.gitconfig Christian Hanser 6. March 2013 Seite 8/8