$ git fetch $REMOTE $BRANCH:$BRANCH
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 and updates
-remote-tracking branch.
+$REMOTE repository that are not in your repository, updates
+remote-tracking branch and leaves the id (the hash) of the head commit
+in file .git/FETCH_HEAD.
The second command fetches commits from the named $BRANCH in the
$REMOTE repository that are not in your repository and updates both
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
''''
For example::
- $ git fetch origin tag 1.4.2 tag 2.1.7
+ $ git fetch origin tag 1.4.2
+ $ git fetch origin v1:v1 tag 2.1.7
Git doesn't automatically pushes tags. That allows you to have private
-tags (lightweight tags are also private for a repo, they cannot be
-pushed). To push tags list them explicitly::
+tags. To push tags list them explicitly::
$ git push origin tag 1.4.2
$ git push origin v1 v2 tag 2.1.7
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 hasn't
+safely edit, remove, reorder, 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 has
+edit them later and force-push edited commits to replace what have
already been pushed. Not a problem until commits are in a public
or shared repository.
---------------------------
``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.)
+commit or commits that revert(s) 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
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 with them - no way.
+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 commits over
-non-committed files.
+to rebase with non-clean working tree. It refuses to pull new commits
+over non-committed files.
-But there are commands that designed exactly for that - overwriting
-files in the working tree. With commands like ``git checkout $PATHs``
-or ``git reset --hard`` git silently overwrites files including your
-uncommitted changes.
+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. But save your changes in git database, either in
-commits or at least in stashes.
+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 between platforms
+with different EOL 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``
+attribute. For binary files the attribute is, naturally, ``binary``.
+
+For example::
+
+ $ cat .gitattributes
+ *.py text
+ *.txt text
+ *.png binary
+ /readme.txt eol=CRLF
+
+To check what attributes git uses for files use ``git check-attr``
+command. For example::
+
+$ git check-attr -a -- \*.py
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
projects / git-wiki.git / blobdiff