Getting up speed with Git
Sharing your work
After mastering Git in a local repository, it's time to share the committed changes with others. One interesting fact comes up:
- Some statistics
KMess required 130MB for the subversion database, 33MB for a checkout of a single revision.
Git needs just 27MB for the full history, and additionally 14MB for a checkout.
In other words, a complete Git clone with full history available offline, is just slightly larger then a single subversion checkout.
Every user has it's own repository in Git.
Each repository is a full clone, with the entire history, compacted in such way it's actually smaller then the actual checkout of one or two commits.
Hence, every developer can work offline with full access to the entire project history. When needed, you can also share your work with other peers before sending the changes the main repository.
Establishing a connection
- Creating a shared repository at a server:
git init --bare projectname.git
Next, the local Git repository can be linked to it:
- Linking the local Git repository to a remote:
git remote add origin remote-url git push origin master
# push your local master to the origin
And you're set up!
To contribute to an existing project, clone the full repository:
- Cloning a repository:
git clone some-url
This will create a local repository, holding the full history of the remote project. The remote location is setup as origin automatically.
New remote changes can be downloaded with:
- Downloading remote changes:
The remote commits will actually live side-by-side in your repository, because they have different SHA1 identifiers. The commits also appear as just another branch in your repository, see:
- Inspecting fetched commits:
git log --all --graph --decorate
# alias it as 'git log-graph'git log --oneline origin/master
# display master branch of origin onlygit branch -a
# display local and remote branches
Integrating remote changes
Any local commits can be reaplied on top of the newly fetched changes:
- Connecting the remote branch:
git rebase origin/master
You can also do git merge instead.
The above steps can be done at once by the git pull command. The pull command uses git merge by default, but it can be changed:
- Letting git pull use rebase:
git pull --rebase
This can also be configured as default, in several ways:
- Setting git pull --rebase by default:
git config branch.master.rebase true
# master branch onlygit config --global branch.autosetuprebase always
# always use rebasegit config --global alias.up "pull --rebase"
# or separate alias
Working at remote branches
To continue working from a remote branch, you'll have to create a local branch first. This is called a "tracking branch". The git clone command already does this for the master branch.
For a second branch, use:
Note how this command is actually a shortcut for:
git branch -t branchname \
git checkout branchname
- Start working on a remote branch:
git checkout -t origin/branch
Any commits at the tracking branch can eventually be pushed to the remote server.
Changes can be submitted with the push command. By default, all matching branches are pushed. To push one branch only, use:
- Pushing the master branch:
git push origin master
Aditionally, some notable parameters are:
|--dry-run||Show what will be pushed|
|--all||Push all branches|
|--tags||Also push tags|
Out of date
The push command complains it can't do a "non fast-forward update". This is complex speak for "your repository is not in sync with the remote one".
Likely, the local branch is out of date or it's not merged with the remote branch. First run git fetch so the local repository is fully updated. With the log command, both branches will appear as disconnected:
- Displaying all branches:
git log --all --graph --decorate --oneline
This can be solved in several ways:
- Fixing a non-fast-forward:
git merge origin/master
# merge the remote branchgit rebase origin/master
# base current commits on top of the remotegit reset origin/master
# throw local changes away
This also happens when you've rewritten history of shared commits.
Extra: sending patches
A user without push access, can extract all commits as patches:
- Extracting patches:
git format-patch origin/master
The developer can apply these patches directly:
- Applying a single patch:
git apply 0001-test.patch git commit --author="Contributor <user@somewhere>
Applying many patches:
- Applying many patches:
git am *.patch
And finally, push the changes.
Internals: reference specifiers
The first argument of the push, pull and fetch commands indicates the remote alias or URL, the second is actually a "refspec". It has the notation localname:remotename.
This allows some weird syntax notations, you'll encounter sometimes:
- Push command syntax:
git push origin master:master
# local master to remote mastergit push origin master
# shortcut for master:mastergit push origin :
# all matching branches (the default)git push origin :branch
# nothing to remote branch -> deletes itgit fetch master:remotes/origin/master
# fetch remote master to local remotes/origin/master
Like commit identifiers, branches have short names, for example:
All these references can be found with internal commands:
- Internal commands to list references:
git show-ref git ls-remote . find .git/refs/ -type f
Coming up next
Sharing changes get nicer by rewriting history beforehand.