This Informational PEP collects information about git. There is, of
course, a lot of documentation for git, so the PEP concentrates on
-more complex issues, scenarios and topics.
+more complex issues, scenarios and examples.
The plan is to extend the PEP in the future collecting information
about equivalence of Mercurial and git scenarios to help migrating
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
---------------------
the currently checked out branch is ``master``. That is, it's assumed
you have done something like that::
- $ git clone http://git.python.org/python.git
+ $ git clone https://git.python.org/python.git
$ cd python
$ git branch v1 origin/v1
The same result can be achieved with commands::
- $ git clone -b v1 http://git.python.org/python.git
+ $ git clone -b v1 https://git.python.org/python.git
$ cd python
$ git checkout --track origin/master
When you do an initial clone like this::
- $ git clone -b v1 http://git.python.org/python.git
+ $ git clone -b v1 https://git.python.org/python.git
+
+git clones remote repository ``https://git.python.org/python.git`` to
+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.
-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.
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.
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 history and finish a
-topic branch with only one last merge commit.
+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
log -p5``.
Some options have arguments, some even have default arguments. In that
-case the argument for such option must be spelled in sticky way:
+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``
grep -Oless`` - in the latter case ``git grep`` passes ``+/pattern``
option to less.
+
bash/zsh completion
-------------------
the latest and greatest download necessary file from `git contrib
<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.
-Git-for-windows comes with git-bash, bash completion is installed and
-enabled.
+Git-for-windows comes with git-bash for which bash completion is
+installed and enabled.
+
bash/zsh prompt
---------------
-For shell command-line lovers prompt can carry a lot of useful
+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>`_.
be configured to allow access with great granularity; gitolite has a
lot of documentation.
-TODO: gitweb; cgit; Kallithea; pagure; gogs and gitea; gitlab.
-
-https://git.kernel.org/cgit/git/git.git/tree/gitweb
+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).
-http://git.zx2c4.com/cgit/
+There are also more advanced web-based development environments that
+include ability to manage users, groups and projects; private, group
+and public repositories; and often include issue trackers, wiki pages,
+pull requests and other tools for development and communication. Among
+these environments are `Kallithea <https://kallithea-scm.org/>`_ and
+`pagure <https://pagure.io/>`_, both are written in Python; pagure was
+written by Fedora developers and is being used to develop some Fedora
+projects. `Gogs <http://gogs.io/>`_ is written in Go; there is a fork
+`Gitea <http://gitea.io/>`_.
-https://kallithea-scm.org/
+And last but not least `Gitlab <https://about.gitlab.com/>`_. It's
+perhaps the most advanced git web-based development environment.
+Written in Ruby, community edition is free and open source (MIT
+license).
-https://pagure.io/
-http://gogs.io/ and http://gitea.io/
+From Mercurial to git
+=====================
-https://about.gitlab.com/
+There are many tools to convert Mercurial repositories to git. The
+most famous are, perhaps, `hg-git <https://hg-git.github.io/>`_ and
+`fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
+it was known under the name ``hg2git``).
+But a better tool, perhaps the best, is `git-remote-hg
+<https://github.com/felipec/git-remote-hg>`_. It provides transparent
+bidirectional access (pull and push) to Mercurial repositories from
+git. The author wrote a `comparison of alternatives
+<https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives>`_
+that seems to be mostly unbiased.
-From Mercurial to git
-=====================
+To use git-remote-hg, install or clone it, add to your PATH (or copy
+script ``git-remote-hg`` to a directory that's already in PATH) and
+prepend ``hg::`` to Mercurial URLs. For example::
-Mercurial for Git users https://mercurial.selenic.com/wiki/GitConcepts
+ $ git clone https://github.com/felipec/git-remote-hg.git
+ $ PATH=$PATH:"`pwd`"/git-remote-hg
+ $ git clone hg::https://hg.python.org/peps/ PEPs
-https://github.com/felipec/git-remote-hg
+To work with the repository just use normal ``git fetch/pull/push``
+commands.
-https://hg-git.github.io/
+Mercurial for Git users https://mercurial.selenic.com/wiki/GitConcepts
References
projects / git-wiki.git / blobdiff