Git - Tutorial
Search Training Books Blog Shop Contact us vogella.com Tutorials
Git - Tutorial
Lars Vogel
Version 5.6 Copyright 2009, 2010, 2011, 2012, 2013, 2014 Lars Vogel 08.02.2014
Revision History Revision 0.1 - 5.6 13.09.2009 - 08.02.2014 Lars Vogel bug fixes and improvements
Training Books
Git Tutorial This tutorial explains the usage of the distributed version control system Git via the command line. The examples were done on Linux (Ubuntu) but should also work on other operating systems like Microsoft Windows.
Table of Contents
1. Git 1.1. What is a version control system? 1.2. What is a distributed version control system? 1.3. What is Git? 1.4. Local repository and operations 1.5. Remote repositories 1.6. Branching and merging 1.7. Working tree 1.8. How to add changes to your Git repository 1.9. Adding to the staging area 1.10. Committing to the repository 1.11. Committing and commit objects 2. Tools 3. Terminology 3.1. Important terms 3.2. File states in Git 4. Commit reference 4.1. Using caret and tilde 4.2. Commit ranges with the double dot operator 4.3. Commit ranges with the triple dot operator 5. Installation 5.1. Ubuntu, Debian and derived systems 5.2. Fedora, Red Hat and derived systems 5.3. Other Linux systems 5.4. Windows
www.vogella.com/tutorials/Git/article.html
1/58
3/6/14
5.5. Mac OS 6. Git Setup 6.1. Global configuration file 6.2. User Configuration 6.3. Push configuration 6.4. Avoid merge commits for pulling 6.5. Color Highlighting 6.6. Setting the default editor 6.7. Setting the default merge tool 6.8. More settings 6.9. Query Git settings
Git - Tutorial
7. Setup rules for ignoring files and directories 7.1. Creating a .gitignore file for your repository 7.2. Global (cross-repository) .gitignore settings 7.3. Local per-repository ignore rules 8. Tracking empty directories with .gitkeep 9. Getting started with Git 9.1. Target of this chapter 9.2. Create directory 9.3. Create Git repository 9.4. Create content 9.5. See the current status of your repository 9.6. Add files to the staging area 9.7. Commit to Git repository 10. Looking at the result 10.1. Results 10.2. Directory structure 11. Remove files and adjust the last commit 11.1. Remove files 11.2. Remove a file from the staging area 11.3. Correct the last commit with git amend 11.4. Remove files based on .gitignore changes 12. Remote repositories 12.1. What are remotes? 12.2. Bare repositories 12.3. Setting up a bare Git repository 12.4. Cloning and the remote called "origin" 12.5. Adding more remote repositories 12.6. Synchronizing with remote repositories 12.7. Show the existing remotes 13. Cloning remote repositories and push and pull 13.1. Clone your repository 13.2. Push changes to another repository 13.3. Pull changes 14. Online remote repositories 14.1. Cloning online repositories 14.2. Add more remote repositories 14.3. Rename remote repositories 14.4. Remote operations via http and a proxy 15. What are branches? 16. Commands to working with branches 16.1. List available branches 16.2. Create new branch 16.3. Checkout branch 16.4. Rename a branch 16.5. Delete a branch 16.6. Push changes of a branch to a remote repository 17. Differences between branches 18. Tags in Git 18.1. What are tags? 18.2. Lightweight and annotated tags
www.vogella.com/tutorials/Git/article.html
2/58
3/6/14
19. Tagging in Git 19.1. List tags 19.2. Search by pattern for a tag 19.3. Creating lightweight tags 19.4. Creating annotated tags 19.5. Signed tags 19.6. Checkout tags 19.7. Push tags 19.8. Delete tags 19.9. Naming conventions for tags
Git - Tutorial
20. Viewing changes in the working tree with git status 20.1. Viewing the status of the working tree with git status 20.2. Example 21. Analyzing the repository history with git log 21.1. Using git log 21.2. Helpful parameters for git log 21.3. View the change history of a file 21.4. Find out which commit deleted a file or directory 21.5. See all commits of a certain user 22. Viewing changes with git diff and git show 22.1. See unstaged changes since the last commit 22.2. See differences between staging area and last commit 22.3. See the differences introduced by a commit 22.4. See the difference between two commits 22.5. See the files changed by a commit 23. Analyzing line changes with git blame 24. git shortlog for release announcements 25. Stashing committed changes with git stash 25.1. The stash command 25.2. Using the Git stash command 26. Remove untracked files with git clean 26.1. Removing untracked files in the working tree 26.2. Example 27. Revert uncommitted changes 27.1. Checkout version from the staging area 27.2. Checkout with staged changes 27.3. Remove staged changes for new files 27.4. Remove staged changes for previously committed files 28. Moving the HEAD pointer with git reset 28.1. Use cases for git reset 28.2. Finding commits which you have reset 28.3. git reset and deleting all unstaged files 28.4. Using git reset to squash commits 29. Retrieving files from the history 29.1. View file in different revision 29.2. Restore a deleted file in a Git repo 29.3. See which commit deleted a file 30. Checkout or revert commits 30.1. Checkout commits versions 30.2. Reverting a commit 31. Recovering lost commits 31.1. Detached HEAD 31.2. git reflog
www.vogella.com/tutorials/Git/article.html
3/58
3/6/14
31.3. Example 32. Remote and local tracking branches
Git - Tutorial
32.1. Remote tracking branches 32.2. Delete a remote tracking branch in your local repository 32.3. Delete a branch in a remote repository 32.4. Tracking branches 32.5. Setting up tracking branches 32.6. See the branch information for a remote repository 33. Updating your remote tracking branches with git fetch 33.1. Fetch 33.2. Fetch from all remote repositories 33.3. Compare remote tracking branch with local branch 33.4. Rebase your local branch onto the remote tracking branch 33.5. Fetch compared with pull 34. Merging 35. Command to merge two branches 36. Merging branches 36.1. Fast-forward merge 36.2. Merge commit 36.3. Specifying merge strategies and parameters 37. Rebase 37.1. Rebasing branches 37.2. Interactive rebase to edit history 37.3. Good practice for rebase 38. Selecting individual commits with git cherry-pick 38.1. Applying a single commit 38.2. Using cherry-pick 39. Solving merge conflicts 39.1. What is a merge conflict 39.2. Example for solving a merge conflict 40. Define alias 40.1. Using an alias 40.2. Alias examples 41. Submodules - repositories inside other Git repositories 41.1. Using submodules 41.2. Updating submodules 41.3. Tracking commits 41.4. Tracking branches with submodules 42. Error search with git bisect 42.1. Using git bisect 42.2. git bisect example 43. Rewriting commit history with git filter-branch 43.1. Using git filter-branch 43.2. filter-branch example 44. Create and apply patches 44.1. What is a patch? 44.2. Create and apply patches 44.3. Create a patch for a selected commit 45. Git commit and other hooks 45.1. Usage of Git hooks 45.2. Client and server side commit hooks
www.vogella.com/tutorials/Git/article.html
4/58
3/6/14
46. Line endings on different platforms 47. Migrating from SVN 48. Frequently asked questions 48.1. Can Git handle symlinks? 49. Git series 50. Get the Book 51. Support free vogella tutorials 51.1. Thank you 51.2. Questions and Discussion 52. Links and Literature
Git - Tutorial
Fast training on version control Subversion & Generic Training amazon.co.uk Get started in minutes! Become an IPv6 Guru ipv6.he.net
Scalable, Secure Web Hosting. Try Our Aw ard-Winning Service Now ! w w w .hostgator.com/1Penny
1. Git
1.1. What is a version control system?
A version control system allows you to track the history of a collection of files and includes the functionality to revert the collection of files to another version. Each version captures a snapshot of the files at a certain point in time. The collection of files is usually source code for a programming language but a typical version control system can put any type of file under version control. The collection of files and their complete history are stored in a repository. The process of creating different versions (snapshots) in the repository is depicted in the following graphic. Please note that this picture fits primarily to Git, other version control systems like CVS don't create snapshots but store file deltas.
These snapshots can be used to change your collection of files. You may, for example, revert the collection of files to a state from 2 days ago. Or you may switch between versions for experimental features.
3/6/14
Git - Tutorial
A distributed version control system does not necessarily have a central server which stores the data. The user can copy an existing repository. This copying process is typically called cloning in a distributed version control system and the resulting repository can be referred to as clone. Typically there is a central server for keeping a repository but each cloned repository is a full copy of this repository. The decision which of the copies is considered to be the central server repository is pure convention and not tied to the capabilities of the distributed version control system itself. Every clone contains the full history of the collection of files and a cloned repository has the same functionality as the original repository. Every repository can exchange versions of the files with other repositories by transporting these changes. This is typically done via a repository running on a server which is, other than the local machine of a developer, always online.
3/6/14
Git - Tutorial
You need to mark changes in the working tree to be relevant for Git. This process is called staging or to add changes to the staging area . You add changes in the working tree to the staging area with the g i ta d dcommand. This command stores a snapshot of the specified files in the staging area . The g i ta d dcommand allows you to incrementally modify files, stage them, modify and stage them again until you are satisfied with your changes.
3/6/14
Git - Tutorial
The staging area keeps track of the snapshots of the files until the staged changes are committed. For committing the staged changes you use the g i tc o m m i tcommand. This process is depicted in the following graphic.
www.vogella.com/tutorials/Git/article.html
8/58
3/6/14
Git - Tutorial
The above picture is simplified. Tree objects point to other tree objects and file blobs. Objects which didn't change between commits are reused by multiple commits.
2. Tools
The original tooling for Git was based on the command line. These days there is a huge variety of available Git tools. You can use graphical tools, for example, the EGit Plugin for the Eclipse IDE. See GUI Clients at the official git website for an overview.
3. Terminology
3.1. Important terms
The following table provides a summary of important Git terminology. Table 1. Git Terminology
Term Branches Definition A branch is a named pointer to a commit. Selecting a branch in Git terminology is called to checkout a branch. If you are working in a certain branch, the creation of a new commit advances this pointer to the newly created commit. Each commit knows their parents (predecessors). Successors are retrieved by traversing the commit graph starting from branches or other refs, symbolic reference (e.g. HEAD) or explicit commit objects. This way a branch defines its own line of descendants in the overall version graph formed by all commits in the repository. You can create a new branch from an existing one and change the code independently from other branches. One of the branches is the default (typically named master). The default branch is the one for which a local branch is automatically created when cloning the repository. Commit When you commit your changes into a repository this creates a new commit object in the Git repository. This commit object uniquely identifies a new revision of the content of the repository. This revision can be retrieved later, for example, if you want to see the source code of an older
www.vogella.com/tutorials/Git/article.html
9/58
3/6/14
Git - Tutorial
version. Each commit object contains the author and the committer, thus making it possible to identify who did the change. The author and committer might be different people. The author did the change and the committer applied the change to the Git repository. HEAD HEAD is a symbolic reference most often pointing to the currently checked out branch. Sometimes the HEAD points directly to a commit object, this is called detached HEAD mode . In that state creation of a commit will not move any branch. The first predecessor of HEAD can be addressed via HEAD~1, HEAD~2 and so on. If you switch branches, the HEAD pointer moves to the last commit in the branch. If you checkout a specific commit, the HEAD points to this commit. Index Repository Index is an alternative term for the staging area. A repository contains the history, the different versions over time and all different branches and tags. In Git each copy of the repository is a complete repository. If the repository is not a bare repository, it allows you to checkout revisions into your working tree and to capture changes by creating new commits. Bare repositories are only changed by transporting changes from other repositories. This book uses the term repository to talk about a non bare repository. If it talks about a bare repository, this is explicitly mentioned. Revision Represents a version of the source code. Git implements revisions as commit objects (or short commits ). These are identified by an SHA-1 secure hash. SHA-1 ids are 160 bits long and are represented in hexadecimal notation. The staging area is the place to store changes in the working tree before the commit. The staging area contains the set of the snapshots of changes in the working tree (change or new files) relevant to create the next commit and stores their mode (file type, executable bit). A tag points to a commit which uniquely identifies a version of the Git repository. With a tag, you can have a named point to which you can always revert to. You can revert to any point in a Git repository, but tags make it easier. The benefit of tags is to mark the repository for a specific reason e.g. with a release. Branches and tags are named pointers, the difference is that branches move when a new commit is created while tags always point to the same commit. Technically, a tag reference can also point to an annotated tag object. URL A URL in Git determines the location of the repository. Git distinguishes between fetchurl for getting new data from other repositories and pushurl for pushing data to another repository. The working tree contains the set of working files for the repository. You can modify the content and commit the changes as new commits to the repository.
Staging area
Tags
Working tree
4. Commit reference
4.1. Using caret and tilde
You can use ^ (caret) and ~ (tilde) to reference predecessor commits objects from other references. Predecessor commits are sometimes also called parent commits. You can combine the ^ and ~ operators. [reference]~1 describes the first predecessor of the commit object accessed via [reference]. [reference]~2 is the first predecessor of the first predecessor of the [reference] commit. [reference]~3 is the first predecessor of the first predecessor of the first predecessor of the [reference] commit, etc.
www.vogella.com/tutorials/Git/article.html 10/58
3/6/14
Git - Tutorial
[reference]~ is an abbreviation for [reference]~1. For example you can use the HEAD~1 or HEAD~ reference to access the first [reference] of the commit to which the HEAD pointer currently points. [reference]^1 also describes the first predecessor of the commit object accessed via [reference]. The difference is that [reference]^2 describes the second predecessor of a commit. A merge commit has two predecessors. [reference]^ is an abbreviation for [reference]^1.
Tip
Think of c1..c2 as all commits as of c1 (not including c1) until commit c2.
For example, you can ask Git to show all commits which happened between HEAD and HEAD~4.
g i tl o gH E A D ~ 4 . . H E A D
This also works for branches. To list all commits which are in the "master" branch but not in the "testing" branch use the following command.
g i tl o gt e s t i n g . . m a s t e r
You can also list all commits which are in the "testing" but not in the "master" branch.
g i tl o gm a s t e r . . t e s t i n g
5. Installation
5.1. Ubuntu, Debian and derived systems
On Ubuntu and similar systems you can install the Git command line tool via the following command:
s u d oa p t g e ti n s t a l lg i t
3/6/14
Git - Tutorial
On Fedora, Red Hat and similar systems you can install the Git command line tool via the following command:
y u mi n s t a l lg i t
5.4. Windows
A windows version of Git can be found on the msysgit Project site. The URL to this webpage is listed below. This website also describes the installation process.
h t t p : / / m s y s g i t . g i t h u b . i o /
5.5. Mac OS
The easiest way to install Git on a Mac is via a graphical installer. This installer can be found under the following URL.
h t t p : / / c o d e . g o o g l e . c o m / p / g i t o s x i n s t a l l e r
As this procedure is not an official Apple one, it may change from time to time. The easiest way to find the current procedure is to Google for the "How to install Git on a Mac" search term. Git is also installed by default with the Apple Developer Tools on Mac OS X.
6. Git Setup
6.1. Global configuration file
Git allows you to store global settings in the . g i t c o n f i gfile located in the user home directory. Git stores the committer and author of a change in each commit. This and additional information can be stored in the global settings. You setup these values with the g i tc o n f i gcommand. In each Git repository you can also configure the settings for this repository. Global configuration is done if you include the g l o b a lflag, otherwise your configuration is specific for the current Git repository. You can also setup system wide configuration. Git stores theses values is in the / e t c / g i t c o n f i gfile, which contains the configuration for every user and repository on the system. To set this up, ensure you have sufficient rights, i.e. root rights, in your OS and use the s y s t e m option. The following configures Git so that a certain user and email address is used, enable color coding and tell Git to ignore certain files.
3/6/14
Git - Tutorial
#c o n f i g u r et h eu s e rw h i c hw i l lb eu s e db yg i t #O fc o u r s ey o us h o u l du s ey o u rn a m e g i tc o n f i gg l o b a lu s e r . n a m e" E x a m p l eS u r n a m e " #S a m ef o rt h ee m a i la d d r e s s g i tc o n f i gg l o b a lu s e r . e m a i l" y o u r . e m a i l @ g m a i l . c o m "
You learn about the push command in Section 13.2, Push changes to another repository.
Note
This setting depends on the individual workflow. Some teams prefer to create merge commits, but the author of this book likes to avoid them.
www.vogella.com/tutorials/Git/article.html
13/58
3/6/14
#t oi n s t a l li tu n d e rU b u n t uu s e s u d oa p t g e ti n s t a l lk d i f f 3
Git - Tutorial
If you want to query the global settings you can use the following command.
g i tc o n f i gg l o b a ll i s t
You can create the . g i t i g n o r efile in the root directory of the working tree to make it specific for the Git repository.
Note
Files that are committed to the Git repository are not automatically removed if you add them to a . g i t i g n o r efile. You can use the g i tr mrc a c h e d [ f i l e n a m e ]command to remove existing files from a Git repository.
Tip
The . g i t i g n o r efile tells Git to ignore the specified files in Git commands. You can still add ignored files to the staging area of the Git repository by using the f o r c eparameter, i.e. with the g i ta d df o r c e[ f i l e n a m e ]command. This is useful if you want to add, for example, auto-generated binaries, but you need to have a fine control about the version which is added and want to exclude them from the normal workflow.
www.vogella.com/tutorials/Git/article.html
14/58
3/6/14
Git - Tutorial
The local . g i t i g n o r efile can be committed into the Git repository and therefore is visible to everyone who clones the repository. The global . g i t i g n o r efile is only locally visible.
Tip
One problem with this approach is that . g i t k e e pis unlikely to be ignored by version control systems or build agents, resulting in . g i t k e e pbeing copied to the output repository. One possible alternative is to create a . g i t k e e pfile in there, which has the same effect but will more likely be ignored by tools that do build processing and filtering of SCM specific resources.
www.vogella.com/tutorials/Git/article.html
15/58
3/6/14
c dr e p o 0 1 #c r e a t ean e wd i r e c t o r y m k d i rd a t a f i l e s
Git - Tutorial
All files inside the repository folder excluding the . g i tfolder are the working tree for a Git repository.
Note
In case you change one of the files again before committing, you need to add it again to the staging area to commit the new changes.
#a d da l lf i l e st ot h ei n d e xo ft h e #G i tr e p o s i t o r y g i ta d d.
3/6/14
Git - Tutorial
www.vogella.com/tutorials/Git/article.html
17/58
3/6/14
Git - Tutorial
#r e m o v et h ef i l ea n dr e c o r dt h ed e l e t i o ni nG i t g i tr mn o n s e n s e 2 . t x t #c o m m i tt h er e m o v a l g i tc o m m i tm" R e m o v e sn o n s e n s e 2 . t x tf i l e "
Tip
Alternatively to the g i tr mcommand you can use the g i tc o m m i tcommand with the aflag or the Aflag in the g i ta d dcommand. This flag adds changes of files known by the Git repository to the commit in case of the g i tc o m m i t command. In case of the g i ta d dcommand it adds all file changes including deletions to the staging area. For this test, commit a new file and remove it afterwards.
#c r e a t eaf i l ea n dp u ti tu n d e rv e r s i o nc o n t r o l t o u c hn o n s e n s e . t x t g i ta d d. g i tc o m m i tm" an e wf i l eh a sb e e nc r e a t e d " #r e m o v et h ef i l e r mn o n s e n s e . t x t #s h o ws t a t u s ,o u t p u tl i s t e db e l o wt h ec o m m a n d g i ts t a t u s #o nb r a n c hm a s t e r #C h a n g e sn o ts t a g e df o rc o m m i t : # ( u s e" g i ta d d / r m< f i l e > . . . "t ou p d a t ew h a tw i l lb ec o m m i t t e d ) # ( u s e" g i tc h e c k o u t-< f i l e > . . . "t od i s c a r dc h a n g e si nw o r k i n gd i r e c t o r y ) # # d e l e t e d : n o n s e n s e . t x t # #n oc h a n g e sa d d e dt oc o m m i t( u s e" g i ta d d "a n d / o r" g i tc o m m i t a " ) #t r ys t a n d a r dw a yo fc o m m i t t i n g>w i l lN O Tw o r k #o u t p u to ft h ec o m m a n dl i s t e db e l o w g i ta d d. g i tc o m m i tm" f i l eh a sN O Tb e e nr e m o v e d " #O nb r a n c hm a s t e r #C h a n g e sn o ts t a g e df o rc o m m i t : # ( u s e" g i ta d d / r m< f i l e > . . . "t ou p d a t ew h a tw i l lb ec o m m i t t e d ) # ( u s e" g i tc h e c k o u t-< f i l e > . . . "t od i s c a r dc h a n g e si nw o r k i n gd i r e c t o r y ) # # d e l e t e d : n o n s e n s e . t x t # #n oc h a n g e sa d d e dt oc o m m i t( u s e" g i ta d d "a n d / o r" g i tc o m m i t a " )
After validating that this command does not remove the file from the Git repository you can use the aparameter. Be aware that the aadds other changes, too.
#c o m m i tt h er e m o v ew i t ht h eaf l a g g i tc o m m i tam" F i l en o n s e n s e . t x ti sn o wr e m o v e d " #a l t e r n a t i v e l yy o uc o u l da d dd e l e t e df i l e st ot h es t a g i n ga r e a v i a #g i ta d dA. #g i tc o m m i tm" F i l en o n s e n s e . t x ti sn o wr e m o v e d "
3/6/14
#c r e a t eaf i l ea n da d dt oi n d e x t o u c hu n w a n t e d s t a g e d . t x t g i ta d du n w a n t e d s t a g e d . t x t #r e m o v ei tf r o mt h ei n d e x g i tr e s e tu n w a n t e d s t a g e d . t x t #t oc l e a n u p ,d e l e t ei t r mu n w a n t e d s t a g e d . t x t
Git - Tutorial
Note
The old commit is still available until a clean-up job remove it. See Section 31.2, git reflog for details.
Assume the last commit message was incorrect as it contained a typo. The following command corrects this via the a m e n dparameter.
#a s s u m ey o uh a v es o m e t h i n gt oc o m m i t g i tc o m m i tm" m e s s a g ew i t hat p y oh e r e "
You should use the g i ta m e n dcommand only for commits which have not been pushed to a public branch of another Git repository. The g i ta m e n dcommand creates a new commit ID and people may have based their work already on the existing commit. In this case they would need to migrate their work based on the new commit.
Note
This does not remove the file from the repository history. If the file should also be removed from the history, have a look at g i tf i l t e r b r a n c h which allows you to rewrite the commit history. See Section 43.1, Using git filterbranch for details.
3/6/14
Git - Tutorial
Such remotes can be used to synchronize the changes of several Git repositories. A local Git repository can be connected to multiple remote repositories and you can synchronize your local repository with them via Git operations.
Note
Think of remotes as shorter bookmarks for repositories. You can always connect to a remote repository if you know its URL and if you have access to it. Without remotes the user would have to type the URL for each and every command which communicates with another repository.
It is possible that users connect their individual repositories directly, but a typically Git workflow involves one or more remote repositories which are used to synchronize the individual repository. Typically the remote repository which is used for synchronization is located on a server which is always available.
Tip
A remote repository can also be hosted in the local file system.
By convention the name of a bare repository should end with the . g i textension.
Note
www.vogella.com/tutorials/Git/article.html 20/58
3/6/14
Git - Tutorial
To create a bare Git repository in the Internet you would, for example, connect to your server via the ssh protocol or you use some Git hosting platform, e.g. Github.com.
Execute the following commands to create a bare repository based on your existing Git repository.
#s w i t c ht ot h ef i r s tr e p o s i t o r y c d~ / r e p o 0 1 #c r e a t ean e wb a r er e p o s i t o r yb yc l o n i n gt h ef i r s to n e g i tc l o n eb a r e.. . / r e m o t e r e p o s i t o r y . g i t #c h e c kt h ec o n t e n to ft h eg i tr e p o ,i ti ss i m i l a r #t ot h e. g i td i r e c t o r yi nr e p o 0 1 #f i l e sm i g h tb ep a c k e di nt h eb a r er e p o s i t o r y l s~ / r e m o t e r e p o s i t o r y . g i t
Tip
You can convert a normal Git repository into a bare repository by moving the content of the . g i tfolder into the root of the repository and removing all others files from the working tree. Afterwards you need to update the Git repository configuration with the g i tc o n f i gc o r e . b a r et r u ecommand. The problem with this process is that it does not take into account potential future internal changes of Git, hence cloning a repository with the b a r eoption should be preferred.
www.vogella.com/tutorials/Git/article.html
21/58
3/6/14
Git - Tutorial
To see the details of the remotes, e.g. the URL use the following command.
#s h o wt h ee x i s t i n gd e f i n e dr e m o t e s g i tr e m o t e #s h o wd e t a i l sa b o u tt h er e m o t e s g i tr e m o t ev
Note
By default you can only push to bare repositories (repositories without working tree). Also you can only push a change to a remote repository which results in a fast-forward merge. See Section 34, Merging to learn about fast-forward merges.
3/6/14
Git - Tutorial
The g i tp u l lcommand allows you to get the latest changes from another repository for the current branch. To test this in your example Git repositories, switch to your second repository, pull in the recent changes in the remote repository, make some changes, push them to your remote repository via the following commands.
#s w i t c ht os e c o n dd i r e c t o r y c d~ / r e p o 0 2 #p u l li nt h el a t e s tc h a n g e so fy o u rr e m o t er e p o s i t o r y g i tp u l l #m a k ec h a n g e s e c h o" Ac h a n g e ">t e s t 0 1 #c o m m i tt h ec h a n g e s g i tc o m m i tam" Ac h a n g e " #p u s hc h a n g e st or e m o t er e p o s i t o r y #o r i g i ni sa u t o m a t i c a l l yc r e a t e da sw ec l o n e do r i g i n a lf r o mt h i sr e p o s i t o r y g i tp u s ho r i g i n
You can pull in the changes in your first example repository with the following commands.
#s w i t c ht ot h ef i r s tr e p o s i t o r ya n dp u l li nt h ec h a n g e s c d~ / r e p o 0 1 g i tp u l l. . / r e m o t e r e p o s i t o r y . g i t / #c h e c kt h ec h a n g e s g i ts t a t u s
Tip
The g i tp u l lcommand is actually a shortcut for g i tf e t c hfollowed by the
g i tm e r g eor g i tr e b a s ecommand depending on your configuration. In
Section 6.4, Avoid merge commits for pulling you configured your Git repository so that g i tp u l lis a fetch followed by a rebase. See Section 33.1, Fetch for more information about the fetch command.
If you have ssh access to a Git repository, you can also use the s s hprotocol. The name preceding @ is the user name used for the ssh connection.
#c l o n eo n l i n er e p o s i t o r y
www.vogella.com/tutorials/Git/article.html
23/58
3/6/14
Git - Tutorial
g i tc l o n es s h : / / g i t @ g i t h u b . c o m / v o g e l l a / g i t b o o k . g i t #o l d e rs y n t a x g i tc l o n eg i t @ g i t h u b . c o m : v o g e l l a / g i t b o o k . g i t
Alternatively you could clone the same repository via the h t t pprotocol.
#T h ef o l l o w i n gw i l lc l o n ev i aH T T P g i tc l o n eh t t p : / / v o g e l l a @ g i t h u b . c o m / v o g e l l a / g i t b o o k . g i t
Note
For secured SSL encrypted communication you should use the ssh or https protocol in order to guarantee security.
www.vogella.com/tutorials/Git/article.html
24/58
3/6/14
Git - Tutorial
#t oc h e c kt h ep r o x ys e t t i n g s g i tc o n f i gg e th t t p . p r o x y #j u s ti nc a s ey o un e e dt oy o uc a na l s or e v o k et h ep r o x ys e t t i n g s g i tc o n f i gg l o b a lu n s e th t t p . p r o x y
Tip
Git is able to store different proxy configurations for different domains, see
c o r e . g i t P r o x yin Git
config manpage.
If you want to see all branches (including remote tracking branches), use the afor the g i tb r a n c h command. See Section 32.1, Remote tracking branches for information about remote tracking branches.
#l i s t sa l lb r a n c h e si n c l u d i n gt h er e m o t eb r a n c h e s g i tb r a n c ha
The voption lists more information about the branches. In order to list branches or tags in a remote repository use the g i tl s r e m o t ecommand as demonstrated in the following example.
#l i s t sb r a n c h e sa n dt a g si nt h e #r e m o t er e p o s i t o r yc a l l e do r i g i n g i tl s r e m o t eo r i g i n
3/6/14
Git - Tutorial
To start working in a branch you have to checkout the branch. If you checkout a branch, the HEAD pointer moves to the last commit in this branch and the files in the working tree are set to the state of this commit. The following commands demonstrates how you switch to the branch called testing, perform some changes in this branch and switch back to the branch called master.
#s w i t c ht oy o u rn e wb r a n c h g i tc h e c k o u tt e s t i n g #d os o m ec h a n g e s e c h o" C o o ln e wf e a t u r ei nt h i sb r a n c h ">t e s t 0 1 g i tc o m m i tam" n e wf e a t u r e " #s w i t c ht ot h em a s t e rb r a n c h g i tc h e c k o u tm a s t e r #c h e c kt h a tt h ec o n t e n to f #t h et e s t 0 1f i l ei st h eo l do n e c a tt e s t 0 1
To create a branch and to switch to it at the same time you can use the g i tc h e c k o u tcommand with the bparameter.
#C r e a t eb r a n c ha n ds w i t c ht oi t g i tc h e c k o u tbb u g r e p o r t 1 2 #C r e a t e san e wb r a n c hb a s e do nt h em a s t e rb r a n c h # w i t h o u tt h el a s tc o m m i t g i tc h e c k o u tbm y b r a n c hm a s t e r ~ 1
This way you can decide which branches you want to push to other repositories and which should be local branches. You learn more about branches and remote repositories in Section 32.1, Remote tracking branches.
www.vogella.com/tutorials/Git/article.html
26/58
3/6/14
Git - Tutorial
You can also use commit ranges as described in Section 4.2, Commit ranges with the double dot operator and Section 4.3, Commit ranges with the triple dot operator. For example, if you compare a branch called your_branch with the master branch the following command shows the changes in your_branch and master since these branches diverged.
#s h o w st h ed i f f e r e n c e si ny o u r #b r a n c hb a s e do nt h ec o m m o n #a n c e s t o rf o rb o t hb r a n c h e s g i td i f fm a s t e r . . . y o u r _ b r a n c h
See Section 22, Viewing changes with git diff and git show for more examples of the g i td i f f command.
www.vogella.com/tutorials/Git/article.html
27/58
3/6/14
g i tt a g1 . 7 . 1 #S e et h et a g g i ts h o w1 . 7 . 1
Git - Tutorial
Warning
If you checkout a tag, you are in the detached head mode and commits created in this mode are harder to find after you checkout a branch again. See Section 31.1, Detached HEAD for details.
www.vogella.com/tutorials/Git/article.html
28/58
3/6/14
Git - Tutorial
20.2. Example
The following commands create some changes in your Git repository.
#m a k es o m ec h a n g e s m ,a s s u m e st h a tt h et e s t 0 1 #a n dt e s t 0 2f i l e se x i s t s #a n dh a v eb e e nc o m m i t t e di nt h ep a s t e c h o" T h i si san e wc h a n g et ot h ef i l e ">t e s t 0 1 e c h o" a n dt h i si sa n o t h e rn e wc h a n g e ">t e s t 0 2 #c r e a t ean e wf i l e l s>n e w f i l e a n a l y z i s . t x t
The g i ts t a t u scommand show the current status of your repository and suggest possible actions.
#s e et h ec u r r e n ts t a t u so fy o u rr e p o s i t o r y #( w h i c hf i l e sa r ec h a n g e d/n e w/d e l e t e d ) g i ts t a t u s
3/6/14
Git - Tutorial
The g i tl o gcommands shows the history of your repository in the current branch, i.e. the list of commits.
#s h o wt h eh i s t o r yo fc o m m i t si nt h ec u r r e n tb r a n c h g i tl o g
#s h o wt h eh i s t o r ya sg r a p hi n c l u d i n gb r a n c h e s g i tl o gg r a p ho n e l i n e
For more options on the g i tl o gcommand see the Git log manpage.
Note
The double hyphens (--) in Git separate flags from non-flags (usually filenames).
www.vogella.com/tutorials/Git/article.html
30/58
3/6/14
Git - Tutorial
www.vogella.com/tutorials/Git/article.html
31/58
3/6/14
Git - Tutorial
#g i tb l a m es h o w st h ea u t h o ra n dc o m m i tp e r #l i n eo faf i l e g i tb l a m e[ f i l e n a m e ] #t h eLo p t i o na l l o w st ol i m i tt h es e l e c t i o n #f o re x a m p l eb yl i n en u m b e r #o n l ys h o wl i n e1a n d2i ng i tb l a m e g i tb l a m eL1 , 2[ f i l e n a m e ]
Tip
You can avoid using the g i ts t a s hcommand. In this case you commit the changes you want to put aside and use the g i tc o m m i ta m e n dcommand to change the commit later. If you use the approach of creating a commit, you typically put a marker in the commit message to mark it as a draft, e.g. " [DRAFT] implement feature x".
3/6/14
Git - Tutorial
#c r e a t eas t a s hw i t hu n c o m m i t t e dc h a n g e s g i ts t a s hs a v e #s e et h el i s to fa v a i l a b l es t a s h e s g i ts t a s hl i s t #R e s u l tm i g h tb es o m e t h i n gl i k e : s t a s h @ { 0 } :W I Po nm a s t e r :2 7 3 e 4 a 0R e s i z ei s s u ei nD i a l o g s t a s h @ { 1 } :W I Po nm a s t e r :2 7 3 e 4 b 0S i l l yt y p oi nC l a s s n a m e s t a s h @ { 2 } :W I Po nm a s t e r :2 7 3 e 4 c 0S i l l yt y p oi nJ a v a d o c #y o uc a nu s et h eI Dt oa p p l yas t a s h g i ts t a s ha p p l ys t a s h @ { 0 } #O ra p p l yt h el a t e s ts t a s ha n dd e l e t ei ta f t e r w a r d s g i ts t a s hp o p #a l s oy o uc a nr e m o v eas t a s h e dc h a n g e #w i t h o u ta p p l y i n gi t g i ts t a s hd r o ps t a s h @ { 0 } #o rd e l e t ea l ls t a s h e s g i ts t a s hc l e a r
25.2.2. Create branch from stash You can also create a branch for your stash if you want to continue to work on the stashed changes in a branch. This can be done with the following command.
#c r e a t ean e wb r a n c hf r o my o u rs t a c ka n d #s w i t c ht oi t g i ts t a s hb r a n c hn e w b r a n c h f o r s t a s h
26.2. Example
The following commands demonstrates the usage of the g i tc l e a ncommand.
#C r e a t ean e wf i l ew i t hc o n t e n t e c h o" t h i si st r a s ht ob ed e l e t e d ">t e s t 0 4 #M a k ead r y r u nt os e ew h a tw o u l dh a p p e n #ni st h es a m ea sd r y r u n g i tc l e a nn #d e l e t e ,fi sr e q u i r e di f #v a r i a b l ec l e a n . r e q u i r e F o r c ei sn o ts e tt of a l s e g i tc l e a nf #u s edf l a gt od e l e t en e wd i r e c t o r i e s #u s ext od e l e t eh i d d e nf i l e s ,e . g ." . e x a m p l e " g i tc l e a nf d x
www.vogella.com/tutorials/Git/article.html
33/58
3/6/14
#i sap a t ha n dn o tap a r a m e t e r #c h a n g eaf i l e e c h o" o v e r r i d e ">t e s t 0 1 #r e s t o r et h ef i l e g i tc h e c k o u t-t e s t 0 1
Git - Tutorial
For example, you can restore a directory called d a t awith the following command.
g i tc h e c k o u t-d a t a
The additional commit pointer parameter instructs the g i tc h e c k o u tcommand to reset the working tree and to also remove the staged changes.
Note
To learn more about the g i tr e s e tcommand see Section 28.1, Use cases for git reset.
www.vogella.com/tutorials/Git/article.html
34/58
3/6/14
Git - Tutorial
Via parameters you can define if the staging area and the working tree is updated. As a reminder, the working tree contains the files and the staging area contains the changes which are marked to be included in the next commit. These parameters are listed in the following table. Table 2. git reset options
Reset HEAD Working tree Staging area
www.vogella.com/tutorials/Git/article.html
35/58
3/6/14
soft mixed (default) hard Yes Yes Yes
Git - Tutorial
No No Yes No Yes Yes
Tip
The g i tr e s e tcommand does not remove untracked files. Use the g i tc l e a n command for this.
28.1.2. Not moving the HEAD pointer with git reset If you specify a path for the g i tr e s e tc o m m a n d , Git does not move the HEAD pointer but only updates the staging area or also the working tree depending on your specified option. See Section 27.3, Remove staged changes for new files and Section 27.4, Remove staged changes for previously committed files for examples.
The interactive rebase adds more flexibility to squashing commits and allows to use the existing commit messages. See Section 37.2, Interactive rebase to edit history for details.
3/6/14
Git - Tutorial
working tree. The following commands demonstrate that. You can also make a copy of the file.
#[ r e f e r e n c e ]c a nb eab r a n c h ,t a g ,H E A Do rc o m m i tI D #[ f i l e n a m e ]i st h ef i l e n a m ei n c l u d i n gp a t h g i ts h o w[ r e f e r e n c e ] : [ f i l e n a m e ] #T om a k eac o p yt oc o p i e d f i l e . t x t g i ts h o w[ r e f e r e n c e ] : [ f i l e n a m e ]>c o p i e d f i l e . t x t
www.vogella.com/tutorials/Git/article.html
37/58
3/6/14
Git - Tutorial
c o m m i t2 6 4 5 d 7 e e f 0 e 2 4 1 9 5 f c 4 0 7 1 3 7 2 0 0 f e 7 e 1 7 9 5 e c f 4 9 A u t h o r :L a r sV o g e l< L a r s . V o g e l @ g m a i l . c o m > D a t e : W e dJ u n51 2 : 0 0 : 5 32 0 1 3+ 0 2 0 0 B u g4 0 9 3 7 3-U p d a t e sv e r s i o nn u m b e ro fe 4C S Ss p yf e a t u r e s
Warning
If you checkout a commit, you are in the detached head mode and commits in this mode are harder to find after you checkout another branch. Before committing it is good practice to create a new branch to leave the detached head mode. See Section 31.1, Detached HEAD for details.
Tip
There are multiple reflogs: one per branch and one for HEAD. For branches use the g i tr e f l o g[ b r a n c h ]command and for HEAD use the g i tr e f l o gor the g i tr e f l o gH E A Dcommand.
www.vogella.com/tutorials/Git/article.html
38/58
3/6/14
Git - Tutorial
31.3. Example
The following example shows how you can use git reflog to reset the current local branch to a commit which isn't reachable from the git log anymore.
#A s s u m et h e I Df o rt h es e c o n dc o m m i ti s #4 5 c a 2 0 4 5 b e 3 a e d a 0 5 4 c 5 4 1 8 e c 3 c 4 c e 6 3 b 5 f 2 6 9 f 7 #R e s e t st h eh e a df o ry o u rt r e et ot h es e c o n dc o m m i t g i tr e s e th a r d4 5 c a 2 0 4 5 b e 3 a e d a 0 5 4 c 5 4 1 8 e c 3 c 4 c e 6 3 b 5 f 2 6 9 f 7 #S e et h el o g g i tl o g #O u t p u ts h o w st h eh i s t o r yu n t i lt h e4 5 c a 2 0 4 5 b ec o m m i t #S e ea l lt h eh i s t o r yi n c l u d i n gt h ed e l e t i o n g i tr e f l o g #< O u t p u t > c f 6 1 6 d 4H E A D @ { 1 } :r e s e t :m o v i n gt o4 5 c a 2 0 4 5 b e 3 a e d a 0 5 4 c 5 4 1 8 e c 3 c 4 c e 6 3 b 5 f 2 6 9 f 7 #. . . s n i p . . . . 1 f 1 a 7 3 aH E A D @ { 2 } :c o m m i t :M o r ec h a a n g e s-t y p oi nt h ec o m m i tm e s s a g e 4 5 c a 2 0 4H E A D @ { 3 } :c o m m i t :T h e s ea r en e wc h a n g e s c f 6 1 6 d 4H E A D @ { 4 } :c o m m i t( i n i t i a l ) :I n i t i a lc o m m i t g i tr e s e th a r d1 f 1 a 7 3 a
To update remote tracking branches without changing local branches you use the g i tf e t c hcommand which is covered in Section 33, Updating your remote tracking branches with git fetch.
The next time you run the g i tf e t c hcommand the remote branch is recreated.
For example if you want to delete the branch called testbranch in the remote repository called origin
www.vogella.com/tutorials/Git/article.html 39/58
3/6/14
Git - Tutorial
Note
Note you can also specify the remote repository's URL. So the following command also works.
g i tp u s hs s h : / / [ U R L _ t o _ r e p o ]: t e s t b r a n c h
Instead of using the g i tc h e c k o u tcommand you can also use the g i tb r a n c hcommand.
#o r i g i n / m a s t e ru s e da se x m a p l eb u tc a nb er e p l a c e d #C r e a t eb r a n c hb a s e do nr e m o t eb r a n c h g i tb r a n c h[ n e w _ b r a n c h ]o r i g i n / m a s t e r #u s et r a c k , #d e f a u l tw h e nt h es t a r tp o i n ti sar e m o t e t r a c k i n gb r a n c h g i tb r a n c ht r a c k[ n e w _ b r a n c h ]o r i g i n / m a s t e r
The n o t r a c kallows you to specify that you do not want to track a branch. You are later going to explicitly add a tracking branch with the g i tb r a n c hucommand.
#i n s t r u c tG i tt oc r e a t eab r a n c hw i t hd o e s #n o tt r a c ka n o t h e rb r a n c h g i tb r a n c hn o t r a c k[ n e w _ b r a n c h _ n o t r a c k ]o r i g i n / m a s t e r #u p d a t et h i sb r a n c ht ot r a c kt h eo r i g i n / m a s t e rb r a n c h g i tb r a n c huo r i g i n / m a s t e r[ n e w _ b r a n c h _ n o t r a c k ]
www.vogella.com/tutorials/Git/article.html
40/58
3/6/14
Git - Tutorial
F e t c hU R L :s s h : / / t e s t @ g i t . e c l i p s e . o r g / g i t r o o t / e 4 / o r g . e c l i p s e . e 4 . t o o l s . g i t P u s h U R L :s s h : / / t e s t @ g i t . e c l i p s e . o r g / g i t r o o t / e 4 / o r g . e c l i p s e . e 4 . t o o l s . g i t H E A Db r a n c h :m a s t e r R e m o t eb r a n c h e s : i n t e g r a t i o n t r a c k e d i n t e r m _ r c 2 t r a c k e d m a s t e r t r a c k e d s m c e l a / H a n d l e r A d d o n U p d a t e st r a c k e d L o c a lb r a n c h e sc o n f i g u r e df o r' g i tp u l l ' : i n t e g r a t i o nr e b a s e so n t or e m o t ei n t e g r a t i o n m a s t e r r e b a s e so n t or e m o t em a s t e r t e s t i n g r e b a s e so n t or e m o t em a s t e r L o c a lr e f sc o n f i g u r e df o r' g i tp u s h ' : i n t e g r a t i o np u s h e st oi n t e g r a t i o n( u pt od a t e ) m a s t e r p u s h e st om a s t e r ( u pt od a t e )
The fetch command only updates the remote tracking branches and none of the local branches and it does not change the working tree of the Git repository. Therefore you can run the g i tf e t c hcommand at any point in time. After reviewing the changes in the remote tracking branch you can merge the changes into your local branches or rebase your local branches onto the remote tracking branch. Alternatively you can also use the g i tc h e r r y p i c k" s h a " command to take over only selected commits.
Tip
A detailed description of merge, rebase and cherry-pick can be found in Section 36, Merging branches.
www.vogella.com/tutorials/Git/article.html
41/58
3/6/14
#s h o was i n g l ed i f f g i td i f fH E A D . . . o r i g i n / m a s t e r #i n s t e a do fu s i n gH E A Dy o uc a na l s o #s p e c i f yt h eb r a n c h e sd i r e c t l y g i td i f fm a s t e ro r i g i n / m a s t e r
Git - Tutorial
The above commands shows the changes introduced in HEAD compared to origin. If you want to see the changes in origin compared to HEAD, you can switch the arguments or use the Rparameter.
33.4. Rebase your local branch onto the remote tracking branch
You can rebase your current local branch onto a remote tracking branch. The following commands demonstrate that.
#a s s u m ey o uw a n tt or e b a s em a s t e rb a s e do nt h el a t e s tf e t c h #t h e r e f o r ec h e c ki to u t g i tc h e c k o u tm a s t e r #u p d a t ey o u rr e m o t et r a c k i n gb r a n c h g i tf e t c h #r e b a s ey o u rm a s t e ro n t oo r i g i n / m a s t e r g i tr e b a s eo r i g i n / m a s t e r
Tip
More information on the rebase command can be found in Section 37.1, Rebasing branches.
34. Merging
Git allows you to combine the changes of two branches. This process is called merging.
3/6/14
Git - Tutorial
After the fast forward merge the HEAD pointer of "master" points to the existing commit.
www.vogella.com/tutorials/Git/article.html
43/58
3/6/14
Git - Tutorial
As a result a so-called merge commit is created on the current branch which is combining the respective changes from the two branches being merged. This commit points to both its predecessors.
Tip
If you prefer to have merge commits, you can avoid fast-forward merges with the g i tm e r g en o f fcommand. This is a question of taste, some teams prefer to always have merge commits, the author of this book prefers fast forward merges.
3/6/14
Git - Tutorial
The sparameter allows you to specify other merge strategies. This is demonstrated with the following command. For example, you can specify the ours strategy in which the result of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. This is demonstrated with the following command.
#m e r g eb r a n c h" o b s o l e t e "i g n o r i n ga l l #c h a n g e si nt h eb r a n c h g i tm e r g eso u r so b s o l e t e
Warning
Be careful if you use the ours merge strategy, it ignores everything from the branch which is merged.
Note
You typically use the ours merge strategy to document in the Git repository that you have integrated a branch and decided to ignore all changes from this branch.
The recursive merge strategy (default) allows you to specify flags with the Xparameter. For example you can specify here the o u r soption. This option forces conflicting changes to be auto-resolved cleanly by favoring the local version. Changes from the other branch that do not conflict with our local version are reflected to the merge result. For a binary file, the entire contents are taken from the local version.
Warning
The o u r soption for the recursive merge strategy should not be confused with the ours merge strategy.
A similar option to o u r sis the t h e i r soption. This option prefers the version from the branch which is merged. Both options are demonstrated in the following example code.
#M e r g ec h a n g e sp r e f e r r i n go u rv e r s i o n g i tm e r g esr e c u r s i v eXo u r s[ b r a n c h _ t o _ m e r g e ] #M e r g ec h a n g e sp r e f e r r i n gt h ev e r s i o nf r o m #t h eb r a n c ht om e r g e g i tm e r g esr e c u r s i v eXt h e i r s[ b r a n c h _ t o _ m e r g e ]
Another useful option is the i g n o r e s p a c e c h a n g eparameter which ignores whitespace changes. For more information about the merge strategies and options see Git merge manpage.
37. Rebase
37.1. Rebasing branches
You can use Git to rebase one branch on another one. As described, the m e r g ecommand combines the changes of two branches. If you rebase a branch called A onto another, the g i tcommand takes the changes introduced by the commits of branch A and applies them based on the HEAD of the other branch. This way the changes in the other branch are also available in branch A. The processes is displayed in the following picture. We want to rebase the branch onto master.
www.vogella.com/tutorials/Git/article.html 45/58
3/6/14
Git - Tutorial
Running the rebase command creates a new commit with the changes of the branch on top of the master branch.
Performing a rebase from one branch to another branch does not create a merge commit. The final result for the source code is the same as with merge but the commit history is cleaner; the history appears to be linear.
#c r e a t en e wb r a n c h g i tc h e c k o u tbr e b a s e t e s t #T os o m ec h a n g e s
www.vogella.com/tutorials/Git/article.html
46/58
3/6/14
Git - Tutorial
t o u c hr e b a s e 1 . t x t g i ta d d.& &g i tc o m m i tm" w o r ki nb r a n c h " #d oc h a n g e si nm a s t e r g i tc h e c k o u tm a s t e r #m a k es o m ec h a n g e sa n dc o m m i ti n t ot e s t i n g e c h o" T h i sw i l lb er e b a s e dt or e b a s e t e s t ">r e b a s e f i l e . t x t g i ta d dr e b a s e f i l e . t x t g i tc o m m i tm" N e wf i l ec r e a t e d " #r e b a s et h er e b a s e t e s to n t om a s t e r g i tc h e c k o u tr e b a s e t e s t g i tr e b a s em a s t e r #n o wy o uc a nf a s tf o r w a r dy o u rb r a n c ho n t om a s t e r g i tc h e c k o u tm a s t e r g i tm e r g er e b a s e t e s t
Rebase can be used to place a feature branch in the local Git repository onto the changes of the master branch. This ensures that your feature is close to the tip of the upstream branch until it is finally published.
Note
There is a price for using rebase: if you rewrite more than one commit by rebasing, you have to test all of the rewritten commits since they are "rewritten" by the rebase algorithm. Since merge/rebase/cherry-pick are purely text-based and do not understand the semantics of these texts they can end up with logically incorrect results, so such commits always should be reviewed and tested in order to detect potential problems. Hence it might be more efficient to merge a long feature branch into upstream instead of rebasing it since with merge you only have to review and test a single commit: the merge commit itself. Whereas with rebase you have to review and test all rebased commits again.
We will combine the last seven commits. You can do this interactively via the following command.
g i tr e b a s eiH E A D ~ 7
www.vogella.com/tutorials/Git/article.html
47/58
3/6/14
Git - Tutorial
This will open your editor of choice and let you configure the rebase operation by defining which commits to pick, squash or fixup. Pick includes the selected commit. Squash combines the commit messages while f i x u pwill disregard the commit message. The following shows an example of the selection, we pick the last commit, squash 5 commits and fix the sixth commit.
p7 c 6 4 7 2 ea d d e dm o r ec o n t e n t f4 f 7 3 e 6 8a d d e dc o n t e n t fb c 9 e c 3 ft h i si sj u s tat e s t f7 0 1 c b b 5u p s f9 1 0 f 3 8 by e s f3 1 d 4 4 7 da d d e dm o r ec o n t e n t se 0 8 d 5 c 3c r e a t i o no fi m p o r t a n tc o n f i g u r a t i o nf i l e #R e b a s e0 6 e 7 4 6 4 . . e 0 8 d 5 c 3o n t o0 6 e 7 4 6 4 # #C o m m a n d s : # p ,p i c k=u s ec o m m i t # r ,r e w o r d=u s ec o m m i t ,b u te d i tt h ec o m m i tm e s s a g e # e ,e d i t=u s ec o m m i t ,b u ts t o pf o ra m e n d i n g # s ,s q u a s h=u s ec o m m i t ,b u tm e l di n t op r e v i o u sc o m m i t # f ,f i x u p=l i k e" s q u a s h " ,b u td i s c a r dt h i sc o m m i t ' sl o gm e s s a g e # x ,e x e c=r u nc o m m a n d( t h er e s to ft h el i n e )u s i n gs h e l l # #T h e s el i n e sc a nb er e o r d e r e d ;t h e ya r ee x e c u t e df r o mt o pt ob o t t o m . # #I fy o ur e m o v eal i n eh e r eT H A TC O M M I TW I L LB EL O S T . #H o w e v e r ,i fy o ur e m o v ee v e r y t h i n g ,t h er e b a s ew i l lb ea b o r t e d .
Warning
Avoid rebasing changes you already shared with others.
For example, assume that a user has a local feature branch and wants to push it onto a branch on the remote repository. However, the branch has evolved and therefore pushing is not possible. Now it is good practice to fetch the latest state of the branch from the remote repository. Afterwards you rebase the local feature branch onto the remote tracking branch. This avoids an unnecessary merge commit. This rebasing of a local feature branch is also useful to incorporate the latest changes from remote into the local development, even if the user does not want to push right away.
Tip
Rebasing and amending commits is safe as long as you did not push any of the changes involved in the rebase. For example, if you cloned a repository and worked in this repository. Rebasing is a great way to keep the history clean when contributing back your modifications.
www.vogella.com/tutorials/Git/article.html
48/58
3/6/14
Git - Tutorial
Warning
In case you want to rewrite history for changes you have shared with others you need to use the fparameter in your g i tp u s hcommand.
#u s i n gf o r c e dp u s h g i tp u s hf
Note
The new commit does not point back to its original commit so do not use cherry-pick blindly since you may end up with several copies of the same change. Most often cherry-pick is either used locally (to emulate r e b a s ei ) or to port individual bug fixes done on a development branch into maintenance branches.
You can check the commit history for example with the g i tl o go n e l i n e command.
#s e ec h a n g ec o m m i th i s t o r y g i tl o go n e l i n e #r e s u l t si nt h ef o l l o w i n go u t p u t 2 f c 2 e 5 5c h a n g e si nf i l e e b b 4 6 b 7a d d sn e wf i l e [ M O R EC O M M I T S ] 3 3 0 b 6 a 3i n i t i a lc o m m i t
The following command selects the first commit based on the commit id and applies its changes to the master branch. This creates a new commit on the master branch.
g i tc h e c k o u tm a s t e r g i tc h e r r y p i c ke b b 4 6 b 7
www.vogella.com/tutorials/Git/article.html
49/58
3/6/14
Git - Tutorial
The c h e r r y p i c kcommand can be used to change the order of commits. g i tc h e r r y p i c kalso accepts commit ranges for example in the following command.
g i tc h e c k o u tm a s t e r #p i c kb o t hc o m m i t s g i tc h e r r y p i c kp i c k t e s t ~ . . p i c k t e s t ~ 1
Tip
See Section 4.2, Commit ranges with the double dot operator for more information about commit ranges.
#G e tt h ec h a n g e sv i aap u l l #t h i sc r e a t e st h em e r g ec o n f l i c ti ny o u r #l o c a lr e p o s i t o r y g i tp u l lo r i g i nm a s t e r
Git marks the conflict in the affected file. This file looks like the following.
< < < < < < <H E A D C h a n g ei nt h ef i r s tr e p o s i t o r y = = = = = = = C h a n g ei nt h es e c o n dr e p o s i t o r y > > > > > > >b 2 9 1 9 6 6 9 2 f 5 e b f d 1 0 d 8 a 9 c a 1 9 1 1 c 8 b 0 8 1 2 7 c 8 5 f 8
The above is the part from your repository and the below one from the remote repository. You can edit
www.vogella.com/tutorials/Git/article.html 50/58
3/6/14
Git - Tutorial
the file manually and afterwards commit the changes. Alternatively, you could use the g i tm e r g e t o o lcommand. g i tm e r g e t o o lstarts a configurable merge tool that displays the changes in a split screen. g i tm e r g e t o o lis not always available. It is also safe to edit the file with merge conflicts in a normal editor.
#E i t h e re d i tt h ef i l em a n u a l l yo ru s e g i tm e r g e t o o l #Y o uw i l lb ep r o m p t e dt os e l e c tw h i c hm e r g et o o ly o uw a n tt ou s e #F o re x a m p l eo nU b u n t uy o uc a nu s et h et o o l" m e l d " #A f t e r m e r g i n gt h ec h a n g e sm a n u a l l y ,c o m m i tt h e m g i tc o m m i tm" m e r g e dc h a n g e s "
Instead of using the moption in the above example you can also use the g i tc o m m i tcommand without this option. In this case the command opens your default editor with a default commit messages about the merged conflicts. It is good practice to use this message.
Free Website Builder Free Government Cell Phone Best Cd Rates 10 Best Mutual Funds Best Mutual Funds Free Music
Equifax Free Credit Report Best Wrinkle Creams Free Credit Report Online Top Smartphones Free Music Downloads Best Credit Cards
Chitika | Opt out?
Or you can define an alias for a detailed g i tl o gcommand. The following command defines the g i tl l alias.
g i tc o n f i gg l o b a la l i a s . l l' l o gg r a p ho n e l i n ed e c o r a t ea l l '
You can also run external commands. In this case you start the alias definition with a !character. For example, the following defines the g i ta ccommand which combines g i ta d d.Aand g i tc o m m i t commands.
#d e f i n ea l i a s g i tc o n f i gg l o b a la l i a s . a c t' ! g i ta d d.A& &g i tc o m m i t ' #t ou s ei t g i ta cm" m e s s a g e "
Warning
In the past msysGit for Windows had problems with an alias beginning with ! , but it has been reported that this now works with msysGit, too .
www.vogella.com/tutorials/Git/article.html
51/58
3/6/14
Git - Tutorial
local configuration file for the submodules if it does not yet exist.
#A d das u b m o d u l et oy o u rG i tr e p o g i ts u b m o d u l ea d d[ U R Lt oG i tr e p o ] #I n i t i a l i z es u b m o d u l ec o n f i g u r a t i o n g i ts u b m o d u l ei n i t
#p u l li nt h ec h a n g e sf r o mm a i nr e p oa n ds u b m o d u l e s g i tp u l lr e c u r s e s u b m o d u l e s
Use the g i ts u b m o d u l eu p d a t e command to set the submodules to the commit specified by the main repository.
#s e t t i n gt h es u b m o d u l e st ot h ec o m m i td e f i n e db ym a s t e r g i ts u b m o d u l eu p d a t e
Warning
The fact that submodules track commits and not branches frequently leads to confusion. That is why Git 1.8.2 added the option to also track branches. Read the following sections to more learn about this.
Warning
This means that if you pull in new changes into the submodules, you need to create a new commit in your main repository in order to track the updates of the nested submodules.
If you update your submodule and want to use this update in your main repository, you need to commit this change in your main repository. The g i ts u b m o d u l eu p d a t ecommand sets the submodule to the commit referred to in the main repository. The following example shows how to update a submodule to its latest commit in its master branch.
www.vogella.com/tutorials/Git/article.html 52/58
3/6/14
Git - Tutorial
#u p d a t es u b m o d u l ei nt h em a s t e rb r a n c h #s k i pt h i si fy o uu s er e c u r s e s u b m o d u l e s #a n dh a v et h em a s t e rb r a n c hc h e c k e do u t c d[ s u b m o d u l ed i r e c t o r y ] g i tc h e c k o u tm a s t e r g i tp u l l #c o m m i tt h ec h a n g ei nm a i nr e p o #t ou s et h el a t e s tc o m m i ti nm a s t e ro ft h es u b m o d u l e c d. . g i ta d d[ s u b m o d u l ed i r e c t o r y ] g i tc o m m i tm" m o v e ds u b m o d u l et ol a t e s tc o m m i ti nm a s t e r " #s h a r ey o u rc h a n g e s g i tp u s h
Another developer can get the update by pulling in the changes and running the submodules update command.
#a n o t h e rd e v e l o p e rw a n t st og e tt h ec h a n g e s g i tp u l l #t h i su p d a t e st h es u b m o d u l et ot h el a t e s t #c o m m i ti nm a s t e ra ss e ti nt h el a s te x a m p l e g i ts u b m o d u l eu p d a t e
Warning
With this setup you are tracking commits, so if the master branch in the submodule moves on, you are still pointing to the existing commit. You need to repeat this procedure every time you want to use new changes of the submodules. See the next chapter for an alternative with a Git release of version 1.8.2 or higher.
3/6/14
Git - Tutorial
We use a simple shell script which checks the existence of a file. Ensure that this file is executable.
# ! / b i n / b a s h F I L E = $ 1 i f[f$ F I L E] ; t h e n e x i t0 ; e l s e e x i t1 ; f i
Afterwards use the g i tb i s e c tcommand to find the bad commit. First you use the g i tb i s e c ts t a r t command to define a commit known to be bad (showing the problem) and a commit known to be good (not showing the problem).
#d e f i n et h a tb i s e c ts h o u l dc h e c k #t h el a s t5c o m m i t s g i tb i s e c ts t a r tH E A DH E A D ~ 5
Tip
The above serves as example. The existence of a file can be easier verified with the g i tb i s e c tcommand: g i tb i s e c tr u nt e s tft e s t 1 . t x t
Warning
Using f i l t e r b r a n c his dangerous as it changes the Git repository. It changes the commit IDs and reacting on such a change requires explicit action from the developer, e.g. he may try to rebase his stale local branch onto the corresponding rewritten remote tracking branch.
Note
A practical case for using g i tf i l t e r b r a n c his where you have added a file which contains a password to the Git repository, and you want to remove the password from the history.
www.vogella.com/tutorials/Git/article.html
54/58
3/6/14
Git - Tutorial
and also contains the diff of any binary data in the commit, for example, an image. This file can be sent to someone else and this developer can use this file to apply the changes to his local repository. The metadata is preserved. Alternatively you could create a diff file with the g i td i f fcommand, but this diff file does not contain the metadata information.
To apply this patch to your master branch in a different clone of the repository, switch to it and use the g i ta p p l ycommand.
#S w i t c ht ot h em a s t e r g i tc h e c k o u tm a s t e r #A p p l yt h ep a t c h g i ta p p l y0 0 0 1 F i r s t c o m m i t i n t h e b r a n c h . p a t c h
Afterwards you can commit the changes introduced by the patches and delete the patch file.
#P a t c hi sa p p l i e dt om a s t e r #C h a n g ec a nb ec o m m i t t e d g i ta d d. g i tc o m m i tam" A p p l i e dp a t c h " #D e l e t et h ep a t c hf i l e r m0 0 0 1 F i r s t c o m m i t i n t h e b r a n c h . p a t c h
www.vogella.com/tutorials/Git/article.html
55/58
3/6/14
Git - Tutorial
Tip
Use the g i ta mcommand to apply and commit the changes in a single step. To apply and commit all patch files in the directory use, for example, the g i t
a m* . p a t c hcommand.
If you create a new Git repository, Git creates example scripts in the . g i t / h o o k sdirectory. The example scripts end with . s a m p l e . To activate them make them executable and remove the . s a m p l e from the filename. The hooks are documented under the following URL: Git hooks manual page.
On Linux and Mac you can tell Git to convert CRLF during a checkout to LF with the following setting.
g i tc o n f i gg l o b a lc o r e . a u t o c r l fi n p u t
www.vogella.com/tutorials/Git/article.html
56/58
3/6/14
Git - Tutorial
Let's say you have a repository called h t t p : / / s v n . e x a m p l e . c o m / r e p owith the default layout (trunk, branches, tags) and already prepared a local git repository where you want to put everything, then navigate to your git directory and use the following commands:
s v n 2 g i th t t p : / / s v n . e x a m p l e . c o m / r e p ov e r b o s e s v n 2 g i tr e b a s e
The parameter v e r b o s eadds detailed output to the commandline so you can see what is going on including potential errors. The second s v n 2 g i tr e b a s ecommand aligns your new git repository with the svn import. You are now ready to push to the web and get forked! If your svn layout deviates from the standard or other problems occur, seek s v n 2 g i th e l pfor documentation on additional parameters.
3/6/14
Git - Tutorial
www.vogella.com/tutorials/Git/article.html
58/58