Git is accompanied with a lot of documentation, both online and
offline.
+
Documentation for starters
--------------------------
`Git workflows
<https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.
+
Advanced documentation
----------------------
`Git Magic
<http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
-also with a number of translations.
+with a number of translations.
`Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at
Amazon or download in PDF, mobi, or ePub form. Has translations to
`Git Wiki <https://git.wiki.kernel.org/index.php/Main_Page>`_.
+
Offline documentation
---------------------
`TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface
to Git based on TortoiseSVN; open source.
+
Initial configuration
---------------------
$ git clone -b v1 http://git.python.org/python.git
git clones remote repository ``http://git.python.org/python.git`` to
-directory ``python``, creates remote-tracking branches, creates a
-local branch ``v1``, configure it to track upstream remotes/origin/v1
-branch and checks out ``v1`` into the working directory.
+directory ``python``, creates a remote named ``origin``, creates
+remote-tracking branches, creates a local branch ``v1``, configure it
+to track upstream remotes/origin/v1 branch and checks out ``v1`` into
+the working directory.
+
Updating local and remote-tracking branches
-------------------------------------------
$REMOTE repository that are not in your repository and updates both
the local branch $BRANCH and its upstream remote-tracking branch. But
it refuses to update branches in case of non-fast-forward. And it
-refuses to update the current branch.
+refuses to update the current branch (currently checked out branch,
+where HEAD is pointing to).
The first command is used internally by ``git pull``.
$ git push origin tag 1.4.2
$ git push origin v1 master tag 2.1.7
+Or push all tags at once::
+
+ $ git push --tags origin
+
Don't move tags with ``git tag -f`` or remove tags with ``git tag -d``
after they have been published.
+
Private information
'''''''''''''''''''
Whatever you do, don't panic. Almost anything in git can be undone.
+
git checkout: restore file's content
------------------------------------
(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
--------------------------------------
difference very clearly. Bare repositories don't have indices or
working trees so in a bare repo only soft reset is possible.
+
Unstaging
'''''''''
<https://git-scm.com/book/en/Git-Basics-Undoing-Things>`_ for details
about unstaging and other undo tricks.
+
git reflog: reference log
-------------------------
$ git cherry-pick save-master~ save-master
$ git branch -D save-master # remove temporary branch
+
git revert: revert a commit
---------------------------
of merge. See the discussion `How to revert a faulty merge
<https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html>`_.
+
One thing that cannot be undone
-------------------------------
Staging area aka index aka cache is a distinguishing feature of git.
Staging area is where git collects patches before committing them.
Separation between collecting patches and commit phases provides a
-very useful feature of git: one can review collected patches before
+very useful feature of git: you can review collected patches before
commit and even edit them - remove some hunks, add new hunks and
review again.
ReReRe
======
-https://git-scm.com/book/en/Git-Tools-Rerere
+Rerere is a mechanism that helps to resolve repeated merge conflicts.
+The most frequent source of recurring merge conflicts are topic
+branches that are merged into mainline and then the merge commits are
+removed; that's often performed to test the topic branches and train
+rerere; merge commits are removed to have clean linear history and
+finish the topic branch with only one last merge commit.
+
+Rerere works by remembering the states of tree before and after a
+successful commit. That way rerere can automatically resolve conflicts
+if they appear in the same files.
+
+Rerere can be used manually with ``git rerere`` command but most often
+it's used automatically. Enable rerere with these commands in a
+working tree::
+
+ $ git config rerere.enabled true
+ $ git config rerere.autoupdate true
+
+You don't need to turn rerere on globally - you don't want rerere in
+bare repositories or repositories without branches; you only need
+rerere in repos where you often perform merges and resolve merge
+conflicts.
+
+See `Rerere <https://git-scm.com/book/en/Git-Tools-Rerere>`_ in The
+Book.
Database maintenance
for explanation on the effects of these parameters.
From time to time run ``git fsck [--strict]`` to verify integrity of
-the database. ``git fsck`` could report dangling objects; that's not
-an error, just a reminder to perform regular maintenance.
+the database. ``git fsck`` may produce a list of dangling objects;
+that's not an error, just a reminder to perform regular maintenance.
Tips and tricks
===============
-TODO: sticky options; example: git grep -O.
+Command-line options and arguments
+----------------------------------
-TODO: tricky options; example: git log -p3.
+`git help cli
+<https://www.kernel.org/pub/software/scm/git/docs/gitcli.html>`_
+recommends not to combine short options/flags. Most of the times it
+works: ``git commit -av`` works perfectly, but there are situations
+when it doesn't. E.g., ``git log -p -5`` cannot be combined as ``git
+log -p5``.
-TODO: bash/zsh completion, bash/zsh prompt.
-https://git.kernel.org/cgit/git/git.git/tree/contrib/completion
+Some options have arguments, some even have default arguments. In that
+case the argument for such option must be spelled in a sticky way:
+``-Oarg``, never ``-O arg`` because for an option that has a default
+argument the latter means "use default value for option ``-O`` and
+pass ``arg`` further to the option parser". For example, ``git grep``
+has an option ``-O`` that passes found files to a program; default
+program for ``-O`` is pager (usually ``less``), but you can use your
+editor::
+ $ git grep -Ovim # but not -O vim
-git on server
-=============
+BTW, there is a difference between running ``git grep -O`` and ``git
+grep -Oless`` - in the latter case ``git grep`` passes ``+/pattern``
+option to less.
+
+
+bash/zsh completion
+-------------------
+
+It's a bit hard to type ``git rebase --interactive --preserve-merges
+HEAD~5`` manually even for those who are happy to use command-line,
+and this is where shell completion is of great help. Bash/zsh come
+with programmable completion, often automatically preinstalled and
+enabled, so if you have bash/zsh and git installed, chances are you
+are already done - just go and use it at the command-line.
-TODO: anonymous access (``git daemon``); git over ssh; gitolite;
-gitweb; cgit; gitlab.
+If you don't have necessary bits preinstalled, install and enable
+bash_completion package. If you want to upgrade your git completion to
+the latest and greatest download necessary file from `git contrib
+<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.
-http://gitolite.com/gitolite/index.html
+Git-for-windows comes with git-bash for which bash completion is
+installed and enabled.
+
+
+bash/zsh prompt
+---------------
+
+For command-line lovers shell prompt can carry a lot of useful
+information. To include git information in the prompt use
+`git-prompt.sh
+<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-prompt.sh>`_.
+Read the detailed instructions in the file.
+
+Search the Net for "git prompt" to find other prompt variants.
+
+
+git on server
+=============
-https://git.kernel.org/cgit/git/git.git/tree/gitweb
+The simplest way to publish a repository or a group of repositories is
+``git daemon``. The daemon provides anonymous access, by default it is
+read-only. The repositories are accessible by git protocol (git://
+URLs). Write access can be enabled but the protocol lacks any
+authentication means, so it should be enabled only within a trusted
+LAN. See ``git help daemon`` for details.
+
+Git over ssh provides authentication and repo-level authorisation as
+repositories can be made user- or group-writeable (see parameter
+``core.sharedRepository`` in ``git help config``). If that's too
+permissive or too restrictive for some project's needs there is a
+wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
+be configured to allow access with great granularity; gitolite has a
+lot of documentation.
+
+Web interface to browse repositories can be created using `gitweb
+<https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ and `cgit
+<http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
+Perl and C). In addition to web interface both provide read-only dumb
+http access for git (http(s):// URLs).
+
+There are also more advanced web-based development environments that
+include ability to create and manage users and groups, private, group
+and public repositories, and usually include issue trackers, wiki
+pages and other developers tools. Among these environments are
+`Kallithea <https://kallithea-scm.org/>`_ and `pagure
+<https://pagure.io/>`_, both are written in Python; `Gogs
+<http://gogs.io/>`_ is written in Go; when its development seemed to
+be stagnated there was a fork `Gitea <http://gitea.io/>`_, still
+active.
+
+And last but not least `Gitlab <https://about.gitlab.com/>`_. It's the
+most advanced web-based development environment. Written in Ruby,
+community edition is free and open source (MIT license).
-http://git.zx2c4.com/cgit/
From Mercurial to git
=====================
projects / git-wiki.git / blobdiff