]> git.phdru.name Git - git-wiki.git/blobdiff - pep-git.txt
Describe ``git reset``
[git-wiki.git] / pep-git.txt
index 6272b08f8042abdc30a7b49171fa6e100286a869..7ac3fb895070f6d015925815837b8b35a374ad8f 100644 (file)
@@ -85,9 +85,8 @@ MacOS X: use git installed with `XCode
 <http://sourceforge.net/projects/git-osx-installer/files/>`_ or
 install git with `Homebrew <http://brew.sh/>`_: ``brew install git``.
 
-`git-cola <https://git-cola.github.io/index.html>`_ is a sleek and
-powerful Git GUI written in Python and GPL licensed. Linux, Windows,
-MacOS X.
+`git-cola <https://git-cola.github.io/index.html>`_ is a Git GUI
+written in Python and GPL licensed. Linux, Windows, MacOS X.
 
 `TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface
 to Git based on TortoiseSVN; open source.
@@ -150,8 +149,8 @@ Labels, on the other hand, can be created, moved, renamed and deleted
 freely.
 
 
-Remote repository and remote branches
-=====================================
+Remote repositories and remote branches
+=======================================
 
 Another example of slightly misleading terminology. Remote
 repositories are really remote, you access them via network (well, a
@@ -174,9 +173,10 @@ To see local and remote branches (and tags) pointing to commits::
 
 You never do your own development on remote branches. You create a
 local branch that has a remote branch as upstream and do development
-on that local branch. On push git updates remote branches, and on pull
-git updates remote branches and fast-forwards, merges or rebases local
-branches.
+on that local branch. On push git pushes commits to the remote repo
+and updates remote branches, on pull git fetches commits from the
+remote repo, updates remote branches and fast-forwards, merges or
+rebases local branches.
 
 When you do an initial clone like this::
 
@@ -381,8 +381,38 @@ or shared repository.
 Undo
 ====
 
-TODO: describe undo strategies: git reset, git revert, git checkout,
-git reflog. "Commit early, commit often".
+Whatever you do, don't panic. Almost anything in git can be undone.
+``git checkout``, for example, can be used to restore the content of
+file(s) to that one of a commit. Like this::
+
+    git checkout HEAD~ README
+
+The commands restores the contente of README file to the last but one
+commit in the current branch. By default a commit ID is simple HEAD;
+i.e. ``git checkout README`` restores README to the latest commit.
+
+(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`` moves the head of the current branch. The head can be
+moved to point to any commit but it's often used to remove a commit or
+a few (preferably, non-pushed ones) from the top of the branch - that
+is, to move the branch backward in order to undo a few non-pushed
+commits.
+
+``git reset`` has three modes of operation - soft, hard and mixed.
+Default is mixed. ProGit `explains
+<https://git-scm.com/book/en/Git-Tools-Reset-Demystified>`_ the
+difference very clearly. Bare repositories don't have indices or
+working trees so in a bare repo only soft reset is possible.
+
+Mixed mode reset with a path or paths can be used to unstage changes -
+that is, to remove changes added with ``git add`` for committing. See
+`The Book <https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things>`_
+for details about unstaging and other undo tricks.
+
+TODO: describe undo strategies: git reflog, git revert.
+"Commit early, commit often".
 
 How to undo a merge
 https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html
@@ -427,7 +457,7 @@ 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 and switch to a new branch
+    $ git checkout -b issue-42  # create a new issue branch and switch to it
         ...edit/test/commit...
     $ git checkout v2
     $ git pull --rebase origin v2  # update v2 from the upstream
@@ -438,9 +468,9 @@ on it. The entire workflow would be something like::
 When the topic branch is deleted only the label is removed, commits
 are stayed in the database, they are now merged into v2::
 
-    o--o--o--o--o--M--< v2 - it is the mainline branch
+    o--o--o--o--o--M--< v2 - the mainline branch
         \         /
-         --*--*--*         - it is the topic branch, now unnamed
+         --*--*--*         - the topic branch, now unnamed
 
 The topic branch is deleted to avoid cluttering branch namespace with
 small topic branches. Information on what issue was fixed or what
@@ -450,7 +480,7 @@ feature was implemented should be in the commit messages.
 Null-merges
 ===========
 
-Git has a builtin strategy for what Python core developers call
+Git has a builtin merge strategy for what Python core developers call
 "null-merge"::
 
     $ git merge -s ours v1  # null-merge v1 into v2
@@ -499,7 +529,10 @@ Tips and tricks
 
 TODO: sticky options; example: git grep -O.
 
+TODO: tricky options; example: git log -p3.
+
 TODO: bash/zsh completion, bash/zsh prompt.
+https://git.kernel.org/cgit/git/git.git/tree/contrib/completion
 
 
 git on server
@@ -507,6 +540,11 @@ git on server
 
 TODO: anonymous access; git over ssh; gitolite; gitweb; cgit; gitlab.
 
+http://gitolite.com/gitolite/index.html
+
+https://git.kernel.org/cgit/git/git.git/tree/gitweb
+
+http://git.zx2c4.com/cgit/
 
 From Mercurial to git
 =====================