Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(300)

Side by Side Diff: docs/git_tips.md

Issue 1314513007: [Docs]: Update to match style guide. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: fixes Created 5 years, 3 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « docs/git_cookbook.md ('k') | docs/gn_check.md » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
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 ```
OLDNEW
« no previous file with comments | « docs/git_cookbook.md ('k') | docs/gn_check.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698