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