PEP: XXX Title: Collecting information about git Version: $Revision$ Last-Modified: $Date$ Author: Oleg Broytman Status: Active Type: Informational Content-Type: text/x-rst Created: 01-Jun-2015 Post-History: Abstract ======== 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, topics and scenarios. 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. Documentation ============= Git is accompanied with a lot of documentation, both online and offline. Documentation for starters -------------------------- Git Tutorial: `part 1 `_, `part 2 `_. `Git User's manual `_. `Everyday GIT With 20 Commands Or So `_. `Git workflows `_. `Git Magic `_, also with a number of translations. Advanced documentation ---------------------- `Pro Git `_. The Book about git. Buy it at Amazon or download in PDF, mobi, or ePub form. Has translations to many different languages. Download Russian translation from `GArik `_. `Git Wiki `_. Offline documentation --------------------- Git has builtin help: run ``git help TOPIC``. For example, run ``git help git`` or ``git help help``. Quick start =========== Download and installation ------------------------- Unix users: download and install using your package manager. Microsoft Windows: download `git-for-windows `_. MacOS X: use git installed with `XCode `_ or download `git-osx-installer `_. Initial configuration --------------------- This simple code is often appears in documentation, but it is important so let repeat it here:: $ git config --global user.name "User Name" $ git config --global user.email user.name@example.org Put your real name and preferred email. Examples in this PEP ==================== Examples of git commands in this PEP use the following approach. It is supposed that you, the user, works with a local repository named ``python`` that has an upstream remote repo named ``origin``. Your local repo has two branches ``v1`` and ``v2``. For most examples the currently checked out branch is ``v2``. That is, it's assumed you did something like that:: $ git clone -b v1 http://git.python.org/python.git $ cd python $ git fetch origin v2:v2 $ git checkout -b v2 Remote repository and remote branches ===================================== Git terminology can be a bit misleading. Take, for example, terms "remote repository" and "remote branches". A remote repository is really remote, you access it via network (well, a remote repository can be on your local disk, but it's still remote because it's not the current repo). Remote branches, on the other hand, are pointers to commits in your local repository. They are there for git to remember what branches and commits have been pushed from and pulled to what remote repos (you can pull from and push to many remotes). To see the status of remote branches:: $ git branch -rv To see local and remote branches (and tags) pointing to commits run:: $ git log --decorate You never do your own development on remote branches. You create a local branch that has a remote branch as an 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. When you do an initial clone like this:: $ git clone -b v1 http://git.python.org/python.git git clones remote repository ``http://git.python.org/python.git`` to directory ``python``, creates remote branches and checks out branch ``v1`` into the working directory. Commit editing and caveats ========================== A warning not to edit published (pushed) commits also appears in documentation but it's also repeated here as it's very important. It is possible to recover from 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 branch:: $ git log origin/v2.. $ git log origin/v1..v1 For every branch that has an upstream remote branch git maintains an alias @{upstream} (short version @{u}), so the commands above can be given as:: $ git log @{u}.. $ git log v1@{u}..v1 To see the status of all branches:: $ git branch -avv To compare the status of local branches with a remote repo:: $ git remote show origin Read `how to recover from upstream rebase `_. 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 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 already been pushed. Not a problem until commits are in a public repository. References ========== .. [] Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: vim: set fenc=us-ascii tw=70 :