OLD | NEW |
(Empty) | |
| 1 When UsingGit, there are a few tips that are particularly useful when working on
the Chromium codebase, especially due to its size. |
| 2 |
| 3 See also GitCookbook. |
| 4 |
| 5 Remember the basic git convention: |
| 6 > `git` _`COMMAND`_ `[`_`FLAGS`_`]` `[`_`ARGUMENTS`_`]` |
| 7 Various git commands have underlying executable with a hyphenated name, such as
`git-grep`, but these can also be called via the `git` wrapper script as `git gr
ep` (and `man` should work either way too). |
| 8 |
| 9 ## Git references |
| 10 |
| 11 The following resources can provide background on how Git works: |
| 12 |
| 13 * [Git-SVN Crash Course](http://git-scm.com/course/svn.html) -- this crash cou
rse is useful for Subversion users switching to Git. |
| 14 * [Think Like (a) Git](http://think-like-a-git.net/) -- does a great job of ex
plaining the main purpose of Git's operations. |
| 15 * [Git User's Manual](http://schacon.github.com/git/user-manual.html) -- a gre
at resource to learn more about how to use Git properly. |
| 16 * [A Visual Git Reference](http://marklodato.github.com/visual-git-guide/index
-en.html) -- a resource that explains various Git operations for visual reasons. |
| 17 * [Git Cheat Sheet](http://cheat.errtheblog.com/s/git) -- now that you underst
and Git, here's a cheat sheet to quickly remind you of all the commands you need
. |
| 18 |
| 19 ## Committing changes |
| 20 For a simple workflow (always commit all changed files, don't keep local revisio
ns), the following script handles check; you may wish to call it `gci` (git comm
it) or similar. |
| 21 |
| 22 Amending a single revision is generally easier for various reasons, notably for
rebasing and for checking that CLs have been committed. However, if you don't us
e local revisions (a local branch with multiple revisions), you should make sure
to upload revisions periodically to code review if you ever need to go to an ol
d version of a CL. |
| 23 ``` |
| 24 #!/bin/bash |
| 25 # Commit all, amending if not initial commit. |
| 26 if git status | grep -q "# Your branch is ahead of 'master' by 1 commit." |
| 27 then |
| 28 git commit --all --amend |
| 29 else |
| 30 git commit --all # initial, not amendment |
| 31 fi |
| 32 ``` |
| 33 |
| 34 ## Listing and changing branches |
| 35 ``` |
| 36 git branch # list branches |
| 37 git checkout - # change to last branch |
| 38 ``` |
| 39 To quickly list the 5 most recent branches, add the following to `.gitconfig` in
the `[alias]` section: |
| 40 ``` |
| 41 last5 = "!git for-each-ref --sort=committerdate refs/heads/ --format='%(committe
rdate:short) %(refname:short)' | tail -5 | cut -c 12-" |
| 42 ``` |
| 43 |
| 44 A nicely color-coded list, sorted in descending order by date, can be made by th
e following bash function: |
| 45 ``` |
| 46 git-list-branches-by-date() { |
| 47 local current_branch=$(git rev-parse --symbolic-full-name --abbrev-ref HEAD) |
| 48 local normal_text=$(echo -ne '\E[0m') |
| 49 local yellow_text=$(echo -ne '\E[0;33m') |
| 50 local yellow_bg=$(echo -ne '\E[7;33m') |
| 51 git for-each-ref --sort=-committerdate \ |
| 52 --format=$' %(refname:short) \t%(committerdate:short)\t%(authorname)\t%(
objectname:short)' refs/heads \ |
| 53 | column -t -s $'\t' -n \ |
| 54 | sed -E "s:^ (${current_branch}) :* ${yellow_bg}\1${normal_text} :" \ |
| 55 | sed -E "s:^ ([^ ]+): ${yellow_text}\1${normal_text}:" |
| 56 } |
| 57 ``` |
| 58 |
| 59 ## Searching |
| 60 Use `git-grep` instead of `grep` and `git-ls-files` instead of `find`, as these
search only files in the index or _tracked_ files in the work tree, rather than
all files in the work tree. |
| 61 |
| 62 Note that `git-ls-files` is rather simpler than `find`, so you'll often need to
use `xargs` instead of `-exec` if you want to process matching files. |
| 63 |
| 64 ## Global changes |
| 65 To make global changes across the source tree, it's often easiest to use `sed` w
ith `git-ls-files`, using `-i` for in-place changing (this is generally safe, as
we don't use symlinks much, but there are few places that do). Remember that yo
u don't need to use `xargs`, since sed can take multiple input files. E.g., to s
trip trailing whitespace from C++ and header files: |
| 66 ``` |
| 67 sed -i -E 's/\s+$//' $(git ls-files '*.cpp' '*.h') |
| 68 ``` |
| 69 |
| 70 You may also find `git-grep` useful for limiting the scope of your changes, usin
g `-l` for listing files. |
| 71 ``` |
| 72 sed -i -E '...' $(git grep -lw Foo '*.cpp' '*.h') |
| 73 ``` |
| 74 |
| 75 Remember that you can restrict sed actions to matching (or non-matching) lines.
For example, to skip lines with a line comment, use the following: |
| 76 ``` |
| 77 '\,//, ! s/foo/bar/g' |
| 78 ``` |
| 79 ## Diffs |
| 80 ``` |
| 81 git diff --shortstat |
| 82 ``` |
| 83 Displays summary statistics, such as: |
| 84 ``` |
| 85 2104 files changed, 9309 insertions(+), 9309 deletions(-) |
| 86 ``` |
OLD | NEW |