Merge conflicts

git mergetool tool meld

Pull
git pull origin master
where origin is the remote and master is the remote branch.
Push
git push origin master
See what is about to be pushed with git push origin master
git log origin/master..master

where origin/master is <remote>/<remote_branch> and last master is the local

branch.

Branching and merging

Branches in Git are local to the respository. A branch created in a local
repository, which was cloned from another repository, does not need to have a
counterpart in the remote repository. Local branches can be compared with other
local branches and with remote tracking branches. A remote tracking branch proxies
the state of a branch in another remote repository.

Working tree
The user works on a collection of files which may originate from a certain point in time of the
repository. The user may also create new files or change and delete existing ones. The current
collection of files is called the working tree.
A standard Git repository contains the working tree (single checkout of one version of the project) and
the full history of the repository. You can work in this working tree by modifying content and
committing the changes to the Git repository.

How to add changes to your Git repository

If you modify your working tree, e.g., by creating a new file or by changing an existing file, you need
to perform two steps in Git to persist the changes in the Git repository. You first add selected files
to the staging area and afterwards you commit the changes of the staging area to the Git
repository.
(The

staging area term is currently preferred by the Git community over the old index term. Both terms
mean the same thing.)

You add changes in the working tree to the staging area with the git add command.
The git add command allows you to incrementally modify files, stage them, modify
and stage them again until you are satisfied with your changes.
After adding the selected files to the staging area, you can commit these files to
permanently add them to the Git repository. Committing creates a new persistent
snapshot (called commit or commit object) of the staging area in the Git
repository. A commit object, like all objects in Git, are immutable.
For committing the staged changes you use the

git commit command.

To commit in only one step you can use:

git commit -a -m "commit directly, without staging, including deletes"
-----------------------

File states in Git

A file in the working tree of a Git repository can have different states. These states are the following:
untracked: the file is not tracked by the Git repository, this means it was neither staged, i.e.
added to the staging area nor committed
tracked: committed and not staged
staged: staged to be included in the next commit
dirty / modified: the file has changed but the change is not staged
--------------------------

Remove a file from the staging area

You can use the git reset [filename] command to remove a file from the staging area, which
you added with git add [filename]. Removing a file from the staging area, avoids that it
included in the next commit.
# create a file and add to staging area
touch unwantedstaged.txt
git add unwantedstaged.txt
# remove it from the staging area
git reset unwantedstaged.txt
# to cleanup, delete it
rm unwantedstaged.txt

What are remotes?

Remotes are URLs in a Git repository to other remote repositories that are hosted on the Internet,
locally or in the network.
Think of remotes as shorter bookmarks for repositories. Without remotes the user
would have to type the URL for each and every command which communicates with
another repository.

Cloning and the remote called "origin"

If you clone a repository, Git implicitly creates a remote named origin by default. The origin remote
links back to the cloned repository.
If you create a Git repository from scratch with the git init command, the origin remote is not
created automatically.
# create a new repository by cloning the first one
git clone ../remote-repository.git .

# clone online repository

git clone git://github.com/vogella/gitbook.git
# the following will clone via HTTP
git clone http://github.com/vogella/gitbook.git

Push changes to another repository

The git push command allows you to send data to other repositories. By default it
sends data from your current branch to the same branch of the remote repository.

By default you can only push to bare repositories (repositories without working
tree).

git push [alias] [branch]

git push github master

Pull changes
The git pull command allows you to get the latest changes from another repository
for the current branch.

# pull in the latest changes of your remote repository

git pull
Git has two commands to update itself from a remote repository. git fetch will synchronize you
with another repo, pulling down any data that you do not have locally and giving you bookmarks to
where each branch on that remote was when you synchronized. These are called "remote branches" and
are identical to local branches except that Git will not allow you to check them out - however, you can
merge from them, diff them to other branches, run history logs on them, etc. You do all of that stuff
locally after you synchronize.
The second command that will fetch down new data from a remote server is git pull
[alias]. This command will basically run a git fetch immediately followed by a git
merge of the branch on that remote that is tracked by whatever branch [alias].

Assuming you have a remote all set up and you want to pull in updates, you would first run git
fetch [alias] to tell Git to fetch down all the data it has that you do not, then you would run git
merge [alias]/[branch] to merge into your current branch anything new you see on the server
(like if someone else has pushed in the meantime). So, if you were working on a Hello World project
with several other people and wanted to bring in any changes that had been pushed since we last
connected, we would do something like this:
$ git fetch github
remote: Counting objects: 4006, done.
remote: Compressing objects: 100% (1322/1322), done.
remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
Resolving deltas: 100% (1526/1526), completed with 387 local objects.
From github.com:schacon/hw
8e29b09..c7c5a10 master
-> github/master
0709fdc..d4ccf73 c-langs
-> github/c-langs
6684f82..ae06d2b java
-> github/java
* [new branch]
ada
-> github/ada
* [new branch]
lisp
-> github/lisp

Here we can see that since we last synchronized with this remote, five branches have been added or
updated. The 'ada' and 'lisp' branches are new, where the 'master', 'c-langs' and 'java' branches have
been updated. In our example case, other developers are pushing proposed updates to remote branches

for review before they're merged into 'master'.

You can see the mapping that Git makes. The 'master' branch on the remote repository becomes a
branch named 'github/master' locally. That way you can merge the 'master' branch on that remote into
the local 'master' branch by running git merge github/master. Or, you can see what new
commits are on that branch by running git log github/master ^master. If your remote is
named 'origin' it would be origin/master instead. Almost any command you would run using local
branches you can use remote branches with too.
If you have more than one remote repository, you can either fetch from specific ones by running git
fetch [alias] or you can tell Git to synchronize with all of your remotes by running git
fetch --all

-------------------------------------------------------------------------------------

-----------------------------

Commit reference
Using caret (^) and tilde (~)
[revision]~1 describes the first predecessor of the commit object accessed via [revision]. [revision]~2 is
the first predecessor of the first predecessor of the [revision] commit. [revision]~3 is the first
predecessor of the first predecessor of the first predecessor of the [reference] commit, etc.
[revision]~ is an abbreviation for [revision]~1.
For example, you can use the HEAD~1 or HEAD~ reference to access the first [revision] 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.

Commit ranges with the double dot operator

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.
git log HEAD~4..HEAD

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.
git log testing..master

Tracking empty directories with .gitkeep

Git ignores empty directories, i.e., it does not put them under version control.
If you want to track such a directory, it is a common practice to put a file called .gitkeep in the
directory. The file could be called anything; Git assigns no special significance to this name. As the
directory now contains a file, Git includes it into its version control mechanism.