from the workstation to a bare repo on the remote host, ssh to the
remote host and pull from the bare repo to a non-bare deployment repo.
+That changed in git 2.3, but see `the blog post
+<https://github.com/blog/1957-git-2-3-has-been-released#push-to-deploy>`_
+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
''''
reset $COMMIT_ID``. Git stores the move of the branch's head in
reflog, so you can undo that undo later again.
+In a more complex situation you'd want to move some commits along with
+resetting the head of the branch. Cherry-pick them to the new branch.
+For example, if you want to reset the branch ``v2`` back to the
+original commit but preserve two commits created in the current branch
+do something like::
+
+ $ git branch save-v2 # create a new branch saving v2
+ $ git reflog # find the original place of v2
+ $ git reset $COMMIT_ID
+ $ git cherry-pick save-v2~ save-v2
+ $ git branch -D save-v2 # remove temporary branch
+
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
+``git revert`` reverts a commit or commits, that is, it creates a new
+commit or commits that reverts the effects of the given commits. It's
+the only way to undo published commits (``git commit --amend``, ``git
+rebase`` and ``git reset`` change the branch in non-fast-forwardable
+ways so they should only be used for non-pushed commits.)
+
+There is a problem with reverting a merge commit. ``git revert`` can
+undo the code created by the merge commit but it cannot undo the fact
+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
-------------------------------
-"Commit early, commit often".
+Whatever you undo, there is one thing that cannot be undone -
+overwritten uncommitted changes. Uncommitted changes don't belong to
+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
+over non-committed files.
+
+But there are commands that do exactly that - overwrite files in the
+working tree. Commands like ``git checkout $PATHs`` or ``git reset
+--hard`` silently overwrite files including your uncommitted changes.
+
+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``.
Merge or rebase?
$ git merge -s ours v1 # null-merge v1 into v2
-ReReRe
-======
+Advanced configuration
+======================
-https://git-scm.com/book/en/Git-Tools-Rerere
+Line endings
+------------
+
+Git has builtin mechanisms to handle line endings.
+
+TODO: describe crlf configuration and .gitattributes.
Advanced topics
Wiki.
-Advanced configuration
-======================
-
-Line endings
-------------
-
-Git has builtin mechanisms to handle line endings.
+ReReRe
+======
-TODO: describe crlf configuration and .gitattributes.
+https://git-scm.com/book/en/Git-Tools-Rerere
Database maintenance