Git terminology can be a bit misleading. Take, for example, the term
"branch". In git it has two meanings. A branch is a directed line of
commits (possibly with merges). And a branch is a label or a pointer
-assigned to a line of commits. It is important to differentiate when
-you talk about commits and when about their labels. Lines of commits
-are by itself unnamed and are usually only lengthening and merging.
+assigned to a line of commits. It is important to distinguish when you
+talk about commits and when about their labels. Lines of commits are
+by itself unnamed and are usually only lengthening and merging.
Labels, on the other hand, can be created, moved, renamed and deleted
freely.
The first command fetches commits from the named BRANCH in the REMOTE
repository that are not in your repository and leaves the id (the
-hash) of the head commit in file .git/FETCH_HEAD. But it doesn't
-update any branch (doesn't move any pointer).
+hash) of the head commit in file .git/FETCH_HEAD and
+updates remote-tracking branch.
The second command fetches commits from the named BRANCH in the REMOTE
repository that are not in your repository and updates both the local
$ git pull
+Default remote repository for fetching/pulling is origin. Default set
+of references to fetch is calculated using matching algorithm: git
+fetches all branches having the same name on both ends.
+
Push
''''
$ git push origin v1 v2
-git guesses (knowing upstream remote branches) that you really want
-
-::
+git pushes local v1 to remote v1 and local v2 to remote v2. The same
+as::
$ git push origin v1:v1 v2:v2
$ git push
+Default remote repository for pushing is origin. Default set
+of references to push in git before 2.0 is calculated using matching
+algorithm: git pushes all branches having the same name on both ends.
+Default set of references to push in git 2.0+ is calculated using
+simple algorithm: git pushes the current branch back to its
+@{upstream}.
+
+To configure git before 2.0 to the new behaviour run::
+
+$ git config push.default simple
+
+To configure git 2.0+ to the old behaviour run::
+
+$ git config push.default matching
+
Git refuses to push a branch if it's the current branch in the remote
non-bare repository: git refuses to update remote working directory.
You really should push only to bare repositories. For non-bare
$ git push origin tag 1.4.2
$ git push origin v1 v2 tag 2.1.7
-Don't move tags with ``git tag -f`` after they have been published.
+Don't move tags with ``git tag -f`` or remove tags with ``git tag -d``
+after they have been published.
Commit editing and caveats
====
Whatever you do, don't panic. Almost anything in git can be undone.
+
+git checkout: restore file's content
+------------------------------------
+
``git checkout``, for example, can be used to restore the content of
file(s) to that one of a commit. Like this::
git checkout HEAD~ README
-The commands restores the contente of README file to the last but one
-commit in the current branch. By default a commit ID is simple HEAD;
+The commands restores the contents of README file to the last but one
+commit in the current branch. By default a commit ID is simply HEAD;
i.e. ``git checkout README`` restores README to the latest commit.
(Do not use ``git checkout`` to view a content of a file in a commit,
use ``git cat-file -p``; e.g. ``git cat-file -p HEAD~:path/to/README``).
+git reset: remove (non-pushed) commits
+--------------------------------------
+
``git reset`` moves the head of the current branch. The head can be
moved to point to any commit but it's often used to remove a commit or
a few (preferably, non-pushed ones) from the top of the branch - that
-is, to move the branch backward in order to undo a few non-pushed
+is, to move the branch backward in order to undo a few (non-pushed)
commits.
``git reset`` has three modes of operation - soft, hard and mixed.
difference very clearly. Bare repositories don't have indices or
working trees so in a bare repo only soft reset is possible.
+Unstaging
+'''''''''
+
Mixed mode reset with a path or paths can be used to unstage changes -
-that is, to remove changes added with ``git add`` for committing. See
-`The Book <https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things>`_
-for details about unstaging and other undo tricks.
+that is, to remove from index changes added with ``git add`` for
+committing. See `The Book
+<https://git-scm.com/book/en/Git-Basics-Undoing-Things>`_ for details
+about unstaging and other undo tricks.
-TODO: describe undo strategies: git reflog, git revert.
-"Commit early, commit often".
+git reflog: reference log
+-------------------------
+
+git revert: revert a commit
+---------------------------
How to undo a merge
https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html
+One thing that cannot be undone
+-------------------------------
+
+"Commit early, commit often".
+
Merge or rebase?
================
====================
TODO: dangling objects, git gc, git repack.
+
https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html
+http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html
+
Tips and tricks
===============
projects / git-wiki.git / blobdiff