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 (and more related to Python development) 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
Python development from Mercurial to git.
The author of the PEP doesn't currently plan to write a Process PEP on
-migration from Mercurial to git.
+migration Python development from Mercurial to git.
Documentation
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
+Amazon or download in PDF, mobi, or ePub form. It has translations to
many different languages. Download Russian translation from `GArik
<https://github.com/GArik/progit/wiki>`_.
`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
=======================================
Remote-tracking branches are branches (pointers to commits) in your
-local repository. They are there for you to remember what branches and
-commits have been pulled from and pushed to what remote repos (you can
-pull from and push to many remotes). Remote-tracking branches live
-under ``remotes/$REMOTE`` namespaces, e.g. ``remotes/origin/master``.
+local repository. They are there for git (and for you) to remember
+what branches and commits have been pulled from and pushed to what
+remote repos (you can pull from and push to many remotes).
+Remote-tracking branches live under ``remotes/$REMOTE`` namespaces,
+e.g. ``remotes/origin/master``.
To see the status of remote-tracking branches run::
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 pull
-Default remote repository for fetching/pulling is origin. Default set
-of references to fetch is calculated using matching algorithm: git
+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
-Default remote repository for pushing is origin. Default set
-of references to push in git before 2.0 is calculated using matching
+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
$ 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
-repositories git prefers pull-based workflow.
+Git doesn't allow 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 repositories git prefers pull-based workflow.
When you want to deploy code on a remote host and can only use push
(because your workstation is behind a firewall and you cannot pull
for caveats; in 2.4 the push-to-deploy feature was `further improved
<https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more#push-to-deploy-improvements>`_.
+
Tags
''''
$ 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
'''''''''''''''''''
private exclude file.
If you want to distribute hooks, copy them to the working tree, add,
-commit, push and instruct the team to update ind install the hook
+commit, push and instruct the team to update and install the hooks
manually.
A warning not to edit published (pushed) commits also appears in
documentation but it's repeated here anyway as it's very important.
-It is possible to recover from forced push but it's PITA for the
+It is possible to recover from a forced push but it's PITA for the
entire team. Please avoid it.
To see what commits have not been published yet compare the head of the
branch with its upstream remote-tracking branch::
- $ git log origin/master..
- $ git log origin/v1..v1
+ $ git log origin/master.. # from origin/master to HEAD (of master)
+ $ git log origin/v1..v1 # from origin/v1 to the head of v1
For every branch that has an upstream remote-tracking branch git
maintains an alias @{upstream} (short version @{u}), so the commands
It is in ``git help rebase``.
On the other hand don't be too afraid about commit editing. You can
-safely edit, remove, reorder, combine and split commits that haven't
+safely edit, reorder, remove, combine and split commits that haven't
been pushed yet. You can even push commits to your own (backup) repo,
edit them later and force-push edited commits to replace what have
already been pushed. Not a problem until commits are in a public
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
-------------------------------
git so git cannot help preserving them.
Most of the time git warns you when you're going to execute a command
-that overwrites uncommitted changes. Git warns you when you try to
-switch branches with ``git checkout``. It warns you when you're going
-to rebase with non-clean working tree. It refuses to pull new commits
+that overwrites uncommitted changes. Git doesn't allow you to switch
+branches with ``git checkout``. It stops you when you're going to
+rebase with non-clean working tree. It refuses to pull new commits
over non-committed files.
But there are commands that do exactly that - overwrite files in the
With that in mind you can understand the stance "commit early, commit
often". Commit as often as possible. Commit on every save in your
-editor or IDE. You can edit your commits before pushing - change,
-reorder, combine, remove. But save your changes in git database,
-either commit changes or at least stash them with ``git stash``.
+editor or IDE. You can edit your commits before pushing - edit commit
+messages, change commits, reorder, combine, split, remove. But save
+your changes in git database, either commit changes or at least stash
+them with ``git stash``.
Merge or rebase?
After that ``git pull origin master`` becomes equivalent to ``git pull
--rebase origin master``.
-In case when merge is preferred it is recommended to create new
-commits in a separate feature or topic branch while using rebase to
-update the mainline branch. When the topic branch is ready merge it
-into mainline. To avoid a tedious task of resolving large number of
-conflicts at once you can merge the topic branch to the mainline from
-time to time and switch back to the topic branch to continue working
-on it. The entire workflow would be something like::
+It is recommended to create new commits in a separate feature or topic
+branch while using rebase to update the mainline branch. When the
+topic branch is ready merge it into mainline. To avoid a tedious task
+of resolving large number of conflicts at once you can merge the topic
+branch to the mainline from time to time and switch back to the topic
+branch to continue working on it. The entire workflow would be
+something like::
$ git checkout -b issue-42 # create a new issue branch and switch to it
...edit/test/commit...
------------
Git has builtin mechanisms to handle line endings between platforms
-with different EOL styles. To allow git to do CRLF conversion assign
-``text`` attribute to files using `.gitattributes
+with different end-of-line styles. To allow git to do CRLF conversion
+assign ``text`` attribute to files using `.gitattributes
<https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html>`_.
-For files that have to have specific line ending assign ``eol``
+For files that have to have specific line endings assign ``eol``
attribute. For binary files the attribute is, naturally, ``binary``.
For example::
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 single-branche repositories; 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
the recommended parameters are ``git repack -a -d -f --depth=20
--window=250``. See `this detailed experiment
<http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html>`_
-for explanation on the effects of these parameters.
+for explanation of 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
+combining 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 a list of names of the found files to
+a program; default program for ``-O`` is a pager (usually ``less``),
+but you can use your editor::
+ $ git grep -Ovim # but not -O vim
-git on server
-=============
+BTW, if git is instructed to use ``less`` as the pager (i.e., if pager
+is not configured in git at all it uses ``less`` by default, or if it
+gets ``less`` from GIT_PAGER or PAGER environment variables, or if it
+was configured with ``git config --global core.pager less``, or
+``less`` is used in the command ``git grep -Oless``) ``git grep``
+passes ``+/$pattern`` option to ``less`` which is quite convenient.
+Unfortunately, ``git grep`` doesn't pass the pattern if the pager is
+not exactly ``less``, even if it's ``less`` with parameters (something
+like ``git config --global core.pager less -FRSXgimq``); fortunately,
+``git grep -Oless`` always passes the pattern.
-TODO: anonymous access (``git daemon``); git over ssh; gitolite;
-gitweb; cgit; gitlab.
-http://gitolite.com/gitolite/index.html
+bash/zsh completion
+-------------------
-https://git.kernel.org/cgit/git/git.git/tree/gitweb
+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 installed 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.
-http://git.zx2c4.com/cgit/
+If you don't have necessary bits installed, 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>`_.
-From Mercurial to git
-=====================
+Git-for-windows comes with git-bash for which bash completion is
+installed and enabled.
-Mercurial for Git users https://mercurial.selenic.com/wiki/GitConcepts
-https://github.com/felipec/git-remote-hg
+bash/zsh prompt
+---------------
-https://hg-git.github.io/
+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.
-References
-==========
-.. []
+git on server
+=============
+
+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 is
+written in Perl and 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>`_ or `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 manage users, groups and projects; private,
+group-accessible and public repositories; they 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/>`_.
+
+And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
+perhaps the most advanced web-based development environment for git.
+Written in Ruby, community edition is free and open source (MIT
+license).
+
+
+From Mercurial to git
+=====================
+
+There are many tools to convert Mercurial repositories to git. The
+most famous are, probably, `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. Its author wrote a `comparison of alternatives
+<https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives>`_
+that seems to be mostly unbiased.
+
+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::
+
+ $ 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
+
+To work with the repository just use regular git commands including
+``git fetch/pull/push``.
+
+To start converting your Mercurial habits to git see the page
+`Mercurial for Git users
+<https://mercurial.selenic.com/wiki/GitConcepts>`_ at Mercurial wiki.
+At the second half of the page there is a table that lists
+corresponding Mercurial and git commands. Should work perfectly in
+both directions.
Copyright
projects / git-wiki.git / blobdiff