From c25a1d42eb825881a592dfda31d0001a600903d5 Mon Sep 17 00:00:00 2001 From: Oleg Broytman Date: Tue, 8 Sep 2015 19:07:38 +0300 Subject: [PATCH] Change wording, add more explanations --- pep-git.txt | 111 +++++++++++++++++++++++++++------------------------- 1 file changed, 57 insertions(+), 54 deletions(-) diff --git a/pep-git.txt b/pep-git.txt index ccbe437..b8171db 100644 --- a/pep-git.txt +++ b/pep-git.txt @@ -14,14 +14,15 @@ 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, scenarios and examples. +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 @@ -55,7 +56,7 @@ Advanced documentation with a number of translations. `Pro Git `_. 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 `_. @@ -158,10 +159,11 @@ Remote repositories and remote branches ======================================= 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:: @@ -323,10 +325,10 @@ To configure git 2.0+ to the old behaviour run:: $ 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 @@ -378,7 +380,7 @@ never cloned, updated or pushed. It's your config, your hooks, your 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. @@ -388,14 +390,14 @@ Commit editing and caveats 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 @@ -417,7 +419,7 @@ 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 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 @@ -539,9 +541,9 @@ 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 +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 @@ -550,9 +552,10 @@ working tree. Commands like ``git checkout $PATHs`` or ``git reset 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? @@ -586,13 +589,13 @@ For example:: 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... @@ -630,10 +633,10 @@ 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 +with different end-of-line styles. To allow git to do CRLF conversion +assign ``text`` attribute to files using `.gitattributes `_. -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:: @@ -711,9 +714,8 @@ working tree:: $ git config rerere.autoupdate true You don't need to turn rerere on globally - you don't want rerere in -bare repositories or repositories without branches; you only need -rerere in repos where you often perform merges and resolve merge -conflicts. +bare repositories or single-branche repositories; you only need rerere +in repos where you often perform merges and resolve merge conflicts. See `Rerere `_ in The Book. @@ -749,7 +751,7 @@ For those who still prefer ``git repack`` over ``git gc --aggressive`` the recommended parameters are ``git repack -a -d -f --depth=20 --window=250``. See `this detailed experiment `_ -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`` may produce a list of dangling objects; @@ -764,25 +766,25 @@ Command-line options and arguments `git help cli `_ -recommends not to combine short options/flags. Most of the times it -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``. +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``. 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 found files to a program; default -program for ``-O`` is pager (usually ``less``), but you can use your -editor:: +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 BTW, there is a difference between running ``git grep -O`` and ``git grep -Oless`` - in the latter case ``git grep`` passes ``+/pattern`` -option to less. +option to ``less``. bash/zsh completion @@ -791,11 +793,11 @@ bash/zsh completion 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 preinstalled and +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. -If you don't have necessary bits preinstalled, install and enable +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 `_. @@ -842,16 +844,17 @@ 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 -and public repositories; and often include issue trackers, wiki pages, -pull requests and other tools for development and communication. Among -these environments are `Kallithea `_ and -`pagure `_, both are written in Python; pagure was -written by Fedora developers and is being used to develop some Fedora -projects. `Gogs `_ is written in Go; there is a fork -`Gitea `_. +and public repositories; they often include issue trackers, wiki +pages, pull requests and other tools for development and +communication. Among these environments are `Kallithea +`_ and `pagure `_, +both are written in Python; pagure was written by Fedora developers +and is being used to develop some Fedora projects. `Gogs +`_ is written in Go; there is a fork `Gitea +`_. And last but not least `Gitlab `_. It's -perhaps the most advanced git web-based development environment. +perhaps the most advanced web-based development environment for git. Written in Ruby, community edition is free and open source (MIT license). -- 2.39.2