be2ea674cc · matheusbsbs/matheus-bagliano

@@ -7,8 +7,8 @@ git-commit - Record changes to the repository

7

8 SYNOPSIS

9 --------

10 -[verse]

11 -'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]

10 +[synopsis]

11 +git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]

12 [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]

13 [-F <file> | -m <msg>] [--reset-author] [--allow-empty]

14 [--allow-empty-message] [--no-verify] [-e] [--author=<author>]

@@ -23,31 +23,31 @@ Create a new commit containing the current contents of the index and

23 the given log message describing the changes. The new commit is a

24 direct child of HEAD, usually the tip of the current branch, and the

25 branch is updated to point to it (unless no branch is associated with

26 -the working tree, in which case HEAD is "detached" as described in

26 +the working tree, in which case `HEAD` is "detached" as described in

27 linkgit:git-checkout[1]).

28

29 The content to be committed can be specified in several ways:

30

31 1. by using linkgit:git-add[1] to incrementally "add" changes to the

32 - index before using the 'commit' command (Note: even modified files

32 + index before using the `commit` command (Note: even modified files

33 must be "added");

34

35 2. by using linkgit:git-rm[1] to remove files from the working tree

36 - and the index, again before using the 'commit' command;

36 + and the index, again before using the `commit` command;

37

38 -3. by listing files as arguments to the 'commit' command

39 - (without --interactive or --patch switch), in which

38 +3. by listing files as arguments to the `commit` command

39 + (without `--interactive` or `--patch` switch), in which

40 case the commit will ignore changes staged in the index, and instead

41 record the current content of the listed files (which must already

42 be known to Git);

43

44 -4. by using the -a switch with the 'commit' command to automatically

44 +4. by using the `-a` switch with the `commit` command to automatically

45 "add" changes from all known files (i.e. all files that are already

46 listed in the index) and to automatically "rm" files in the index

47 that have been removed from the working tree, and then perform the

48 actual commit;

49

50 -5. by using the --interactive or --patch switches with the 'commit' command

50 +5. by using the `--interactive` or `--patch` switches with the `commit` command

51 to decide one by one which files or hunks should be part of the commit

52 in addition to contents in the index,

53 before finalizing the operation. See the ``Interactive Mode'' section of

@@ -58,137 +58,137 @@ summary of what is included by any of the above for the next

58 commit by giving the same set of parameters (options and paths).

59

60 If you make a commit and then find a mistake immediately after

61 -that, you can recover from it with 'git reset'.

61 +that, you can recover from it with `git reset`.

62

63 :git-commit: 1

64

65 OPTIONS

66 -------

67 --a::

68 ---all::

67 +`-a`::

68 +`--all`::

69 Tell the command to automatically stage files that have

70 been modified and deleted, but new files you have not

71 told Git about are not affected.

72

73 --p::

74 ---patch::

73 +`-p`::

74 +`--patch`::

75 Use the interactive patch selection interface to choose

76 which changes to commit. See linkgit:git-add[1] for

77 details.

78

79 --C <commit>::

80 ---reuse-message=<commit>::

81 - Take an existing commit object, and reuse the log message

79 +`-C <commit>`::

80 +`--reuse-message=<commit>`::

81 + Take an existing _<commit>_ object, and reuse the log message

82 and the authorship information (including the timestamp)

83 when creating the commit.

84

85 --c <commit>::

86 ---reedit-message=<commit>::

87 - Like '-C', but with `-c` the editor is invoked, so that

85 +`-c <commit>`::

86 +`--reedit-message=<commit>`::

87 + Like `-C`, but with `-c` the editor is invoked, so that

88 the user can further edit the commit message.

89

90 ---fixup=[(amend|reword):]<commit>::

91 - Create a new commit which "fixes up" `<commit>` when applied with

90 +`--fixup=[(amend|reword):]<commit>`::

91 + Create a new commit which "fixes up" _<commit>_ when applied with

92 `git rebase --autosquash`. Plain `--fixup=<commit>` creates a

93 - "fixup!" commit which changes the content of `<commit>` but leaves

93 + "fixup!" commit which changes the content of _<commit>_ but leaves

94 its log message untouched. `--fixup=amend:<commit>` is similar but

95 creates an "amend!" commit which also replaces the log message of

96 - `<commit>` with the log message of the "amend!" commit.

96 + _<commit>_ with the log message of the "amend!" commit.

97 `--fixup=reword:<commit>` creates an "amend!" commit which

98 - replaces the log message of `<commit>` with its own log message

99 - but makes no changes to the content of `<commit>`.

98 + replaces the log message of _<commit>_ with its own log message

99 + but makes no changes to the content of _<commit>_.

100 +

101 The commit created by plain `--fixup=<commit>` has a subject

102 -composed of "fixup!" followed by the subject line from <commit>,

102 +composed of "fixup!" followed by the subject line from _<commit>_,

103 and is recognized specially by `git rebase --autosquash`. The `-m`

104 option may be used to supplement the log message of the created

105 commit, but the additional commentary will be thrown away once the

106 -"fixup!" commit is squashed into `<commit>` by

106 +"fixup!" commit is squashed into _<commit>_ by

107 `git rebase --autosquash`.

108 +

109 The commit created by `--fixup=amend:<commit>` is similar but its

110 subject is instead prefixed with "amend!". The log message of

111 -<commit> is copied into the log message of the "amend!" commit and

111 +_<commit>_ is copied into the log message of the "amend!" commit and

112 opened in an editor so it can be refined. When `git rebase

113 ---autosquash` squashes the "amend!" commit into `<commit>`, the

114 -log message of `<commit>` is replaced by the refined log message

113 +--autosquash` squashes the "amend!" commit into _<commit>_, the

114 +log message of _<commit>_ is replaced by the refined log message

115 from the "amend!" commit. It is an error for the "amend!" commit's

116 log message to be empty unless `--allow-empty-message` is

117 specified.

118 +

119 `--fixup=reword:<commit>` is shorthand for `--fixup=amend:<commit>

120 ---only`. It creates an "amend!" commit with only a log message

120 + --only`. It creates an "amend!" commit with only a log message

121 (ignoring any changes staged in the index). When squashed by `git

122 -rebase --autosquash`, it replaces the log message of `<commit>`

122 +rebase --autosquash`, it replaces the log message of _<commit>_

123 without making any other changes.

124 +

125 Neither "fixup!" nor "amend!" commits change authorship of

126 -`<commit>` when applied by `git rebase --autosquash`.

126 +_<commit>_ when applied by `git rebase --autosquash`.

127 See linkgit:git-rebase[1] for details.

128

129 ---squash=<commit>::

130 - Construct a commit message for use with `rebase --autosquash`.

129 +`--squash=<commit>`::

130 + Construct a commit message for use with `git rebase --autosquash`.

131 The commit message subject line is taken from the specified

132 commit with a prefix of "squash! ". Can be used with additional

133 commit message options (`-m`/`-c`/`-C`/`-F`). See

134 linkgit:git-rebase[1] for details.

135

136 ---reset-author::

137 - When used with -C/-c/--amend options, or when committing after a

136 +`--reset-author`::

137 + When used with `-C`/`-c`/`--amend` options, or when committing after a

138 conflicting cherry-pick, declare that the authorship of the

139 resulting commit now belongs to the committer. This also renews

140 the author timestamp.

141

142 ---short::

142 +`--short`::

143 When doing a dry-run, give the output in the short-format. See

144 linkgit:git-status[1] for details. Implies `--dry-run`.

145

146 ---branch::

146 +`--branch`::

147 Show the branch and tracking info even in short-format.

148

149 ---porcelain::

149 +`--porcelain`::

150 When doing a dry-run, give the output in a porcelain-ready

151 format. See linkgit:git-status[1] for details. Implies

152 `--dry-run`.

153

154 ---long::

154 +`--long`::

155 When doing a dry-run, give the output in the long-format.

156 Implies `--dry-run`.

157

158 --z::

159 ---null::

158 +`-z`::

159 +`--null`::

160 When showing `short` or `porcelain` status output, print the

161 - filename verbatim and terminate the entries with NUL, instead of LF.

161 + filename verbatim and terminate the entries with _NUL_, instead of _LF_.

162 If no format is given, implies the `--porcelain` output format.

163 Without the `-z` option, filenames with "unusual" characters are

164 quoted as explained for the configuration variable `core.quotePath`

165 (see linkgit:git-config[1]).

166

167 --F <file>::

168 ---file=<file>::

167 +`-F <file>`::

168 +`--file=<file>`::

169 Take the commit message from the given file. Use '-' to

170 read the message from the standard input.

171

172 ---author=<author>::

172 +`--author=<author>`::

173 Override the commit author. Specify an explicit author using the

174 - standard `A U Thor <author@example.com>` format. Otherwise <author>

174 + standard `A U Thor <author@example.com>` format. Otherwise _<author>_

175 is assumed to be a pattern and is used to search for an existing

176 - commit by that author (i.e. rev-list --all -i --author=<author>);

176 + commit by that author (i.e. `git rev-list --all -i --author=<author>`);

177 the commit author is then copied from the first such commit found.

178

179 ---date=<date>::

179 +`--date=<date>`::

180 Override the author date used in the commit.

181

182 --m <msg>::

183 ---message=<msg>::

182 +`-m <msg>`::

183 +`--message=<msg>`::

184 Use the given <msg> as the commit message.

185 If multiple `-m` options are given, their values are

186 concatenated as separate paragraphs.

187 +

188 The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.

189

190 --t <file>::

191 ---template=<file>::

190 +`-t <file>`::

191 +`--template=<file>`::

192 When editing the commit message, start the editor with the

193 contents in the given file. The `commit.template` configuration

194 variable is often used to give this option implicitly to the

@@ -200,56 +200,56 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.

200

201 include::signoff-option.txt[]

202

203 ---trailer <token>[(=|:)<value>]::

204 - Specify a (<token>, <value>) pair that should be applied as a

203 +`--trailer <token>[(=|:)<value>]`::

204 + Specify a (_<token>_, _<value>_) pair that should be applied as a

205 trailer. (e.g. `git commit --trailer "Signed-off-by:C O Mitter \

206 <committer@example.com>" --trailer "Helped-by:C O Mitter \

207 - <committer@example.com>"` will add the "Signed-off-by" trailer

208 - and the "Helped-by" trailer to the commit message.)

207 + <committer@example.com>"` will add the `Signed-off-by` trailer

208 + and the `Helped-by` trailer to the commit message.)

209 The `trailer.*` configuration variables

210 (linkgit:git-interpret-trailers[1]) can be used to define if

211 a duplicated trailer is omitted, where in the run of trailers

212 each trailer would appear, and other details.

213

214 --n::

215 ---[no-]verify::

214 +`-n`::

215 +`--[no-]verify`::

216 By default, the pre-commit and commit-msg hooks are run.

217 When any of `--no-verify` or `-n` is given, these are bypassed.

218 See also linkgit:githooks[5].

219

220 ---allow-empty::

220 +`--allow-empty`::

221 Usually recording a commit that has the exact same tree as its

222 sole parent commit is a mistake, and the command prevents you

223 from making such a commit. This option bypasses the safety, and

224 is primarily for use by foreign SCM interface scripts.

225

226 ---allow-empty-message::

227 - Like --allow-empty this command is primarily for use by foreign

226 +`--allow-empty-message`::

227 + Like `--allow-empty` this command is primarily for use by foreign

228 SCM interface scripts. It allows you to create a commit with an

229 empty commit message without using plumbing commands like

230 linkgit:git-commit-tree[1].

231

232 ---cleanup=<mode>::

232 +`--cleanup=<mode>`::

233 This option determines how the supplied commit message should be

234 cleaned up before committing. The '<mode>' can be `strip`,

235 `whitespace`, `verbatim`, `scissors` or `default`.

236 +

237 --

238 -strip::

238 +`strip`::

239 Strip leading and trailing empty lines, trailing whitespace,

240 commentary and collapse consecutive empty lines.

241 -whitespace::

241 +`whitespace`::

242 Same as `strip` except #commentary is not removed.

243 -verbatim::

243 +`verbatim`::

244 Do not change the message at all.

245 -scissors::

245 +`scissors`::

246 Same as `whitespace` except that everything from (and including)

247 the line found below is truncated, if the message is to be edited.

248 - "`#`" can be customized with core.commentChar.

248 + "`#`" can be customized with `core.commentChar`.

249

250 # ------------------------ >8 ------------------------

251

252 -default::

252 +`default`::

253 Same as `strip` if the message is to be edited.

254 Otherwise `whitespace`.

255 --

@@ -257,19 +257,19 @@ default::

257 The default can be changed by the `commit.cleanup` configuration

258 variable (see linkgit:git-config[1]).

259

260 --e::

261 ---edit::

260 +`-e`::

261 +`--edit`::

262 The message taken from file with `-F`, command line with

263 `-m`, and from commit object with `-C` are usually used as

264 the commit log message unmodified. This option lets you

265 further edit the message taken from these sources.

266

267 ---no-edit::

267 +`--no-edit`::

268 Use the selected commit message without launching an editor.

269 For example, `git commit --amend --no-edit` amends a commit

270 without changing its commit message.

271

272 ---amend::

272 +`--amend`::

273 Replace the tip of the current branch by creating a new

274 commit. The recorded tree is prepared as usual (including

275 the effect of the `-i` and `-o` options and explicit

@@ -295,23 +295,23 @@ You should understand the implications of rewriting history if you

295 amend a commit that has already been published. (See the "RECOVERING

296 FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)

297

298 ---no-post-rewrite::

299 - Bypass the post-rewrite hook.

298 +`--no-post-rewrite`::

299 + Bypass the `post-rewrite` hook.

300

301 --i::

302 ---include::

301 +`-i`::

302 +`--include`::

303 Before making a commit out of staged contents so far,

304 stage the contents of paths given on the command line

305 as well. This is usually not what you want unless you

306 are concluding a conflicted merge.

307

308 --o::

309 ---only::

308 +`-o`::

309 +`--only`::

310 Make a commit by taking the updated working tree contents

311 of the paths specified on the

312 command line, disregarding any contents that have been

313 staged for other paths. This is the default mode of operation of

314 - 'git commit' if any paths are given on the command line,

314 + `git commit` if any paths are given on the command line,

315 in which case this option can be omitted.

316 If this option is specified together with `--amend`, then

317 no paths need to be specified, which can be used to amend

@@ -319,48 +319,48 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)

319 already been staged. If used together with `--allow-empty`

320 paths are also not required, and an empty commit will be created.

321

322 ---pathspec-from-file=<file>::

323 - Pathspec is passed in `<file>` instead of commandline args. If

324 - `<file>` is exactly `-` then standard input is used. Pathspec

325 - elements are separated by LF or CR/LF. Pathspec elements can be

322 +`--pathspec-from-file=<file>`::

323 + Pathspec is passed in _<file>_ instead of commandline args. If

324 + _<file>_ is exactly `-` then standard input is used. Pathspec

325 + elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be

326 quoted as explained for the configuration variable `core.quotePath`

327 (see linkgit:git-config[1]). See also `--pathspec-file-nul` and

328 global `--literal-pathspecs`.

329

330 ---pathspec-file-nul::

330 +`--pathspec-file-nul`::

331 Only meaningful with `--pathspec-from-file`. Pathspec elements are

332 - separated with NUL character and all other characters are taken

332 + separated with _NUL_ character and all other characters are taken

333 literally (including newlines and quotes).

334

335 --u[<mode>]::

336 ---untracked-files[=<mode>]::

335 +`-u[<mode>]`::

336 +`--untracked-files[=<mode>]`::

337 Show untracked files.

338 +

339 --

340 -The mode parameter is optional (defaults to 'all'), and is used to

341 -specify the handling of untracked files; when -u is not used, the

342 -default is 'normal', i.e. show untracked files and directories.

340 +The _<mode>_ parameter is optional (defaults to `all`), and is used to

341 +specify the handling of untracked files; when `-u` is not used, the

342 +default is `normal`, i.e. show untracked files and directories.

343

344 The possible options are:

345

346 - - 'no' - Show no untracked files

347 - - 'normal' - Shows untracked files and directories

348 - - 'all' - Also shows individual files in untracked directories.

346 +`no`:: Show no untracked files

347 +`normal`:: Shows untracked files and directories

348 +`all`:: Also shows individual files in untracked directories.

349

350 All usual spellings for Boolean value `true` are taken as `normal`

351 and `false` as `no`.

352 -The default can be changed using the status.showUntrackedFiles

352 +The default can be changed using the `status.showUntrackedFiles`

353 configuration variable documented in linkgit:git-config[1].

354 --

355

356 --v::

357 ---verbose::

358 - Show unified diff between the HEAD commit and what

356 +`-v`::

357 +`--verbose`::

358 + Show unified diff between the `HEAD` commit and what

359 would be committed at the bottom of the commit message

360 template to help the user describe the commit by reminding

361 what changes the commit has.

362 Note that this diff output doesn't have its

363 - lines prefixed with '#'. This diff will not be a part

363 + lines prefixed with `#`. This diff will not be a part

364 of the commit message. See the `commit.verbose` configuration

365 variable in linkgit:git-config[1].

366 +

@@ -368,40 +368,40 @@ If specified twice, show in addition the unified diff between

368 what would be committed and the worktree files, i.e. the unstaged

369 changes to tracked files.

370

371 --q::

372 ---quiet::

371 +`-q`::

372 +`--quiet`::

373 Suppress commit summary message.

374

375 ---dry-run::

375 +`--dry-run`::

376 Do not create a commit, but show a list of paths that are

377 to be committed, paths with local changes that will be left

378 uncommitted and paths that are untracked.

379

380 ---status::

380 +`--status`::

381 Include the output of linkgit:git-status[1] in the commit

382 message template when using an editor to prepare the commit

383 message. Defaults to on, but can be used to override

384 - configuration variable commit.status.

384 + configuration variable `commit.status`.

385

386 ---no-status::

386 +`--no-status`::

387 Do not include the output of linkgit:git-status[1] in the

388 commit message template when using an editor to prepare the

389 default commit message.

390

391 --S[<keyid>]::

392 ---gpg-sign[=<keyid>]::

393 ---no-gpg-sign::

394 - GPG-sign commits. The `keyid` argument is optional and

391 +`-S[<key-id>]`::

392 +`--gpg-sign[=<key-id>]`::

393 +`--no-gpg-sign`::

394 + GPG-sign commits. The _<key-id>_ is optional and

395 defaults to the committer identity; if specified, it must be

396 stuck to the option without a space. `--no-gpg-sign` is useful to

397 countermand both `commit.gpgSign` configuration variable, and

398 earlier `--gpg-sign`.

399

400 -\--::

400 +`--`::

401 Do not interpret any more arguments as options.

402

403 -<pathspec>...::

404 - When pathspec is given on the command line, commit the contents of

403 +`<pathspec>...`::

404 + When _<pathspec>_ is given on the command line, commit the contents of

405 the files that match the pathspec without recording the changes

406 already added to the index. The contents of these files are also

407 staged for the next commit on top of what have been staged before.

@@ -412,10 +412,10 @@ EXAMPLES

412 --------

413 When recording your own work, the contents of modified files in

414 your working tree are temporarily stored to a staging area

415 -called the "index" with 'git add'. A file can be

415 +called the "index" with `git add`. A file can be

416 reverted back, only in the index but not in the working tree,

417 to that of the last commit with `git restore --staged <file>`,

418 -which effectively reverts 'git add' and prevents the changes to

418 +which effectively reverts `git add` and prevents the changes to

419 this file from participating in the next commit. After building

420 the state to be committed incrementally with these commands,

421 `git commit` (without any pathname parameter) is used to record what

@@ -443,7 +443,7 @@ $ git commit -a

443 ------------

444

445 The command `git commit -a` first looks at your working tree,

446 -notices that you have modified hello.c and removed goodbye.c,

446 +notices that you have modified `hello.c` and removed `goodbye.c`,

447 and performs necessary `git add` and `git rm` for you.

448

449 After staging changes to many files, you can alter the order the

@@ -471,13 +471,13 @@ $ git commit

471 this second commit would record the changes to `hello.c` and

472 `hello.h` as expected.

473

474 -After a merge (initiated by 'git merge' or 'git pull') stops

474 +After a merge (initiated by `git merge` or `git pull`) stops

475 because of conflicts, cleanly merged

476 paths are already staged to be committed for you, and paths that

477 conflicted are left in unmerged state. You would have to first

478 -check which paths are conflicting with 'git status'

478 +check which paths are conflicting with `git status`

479 and after fixing them manually in your working tree, you would

480 -stage the result as usual with 'git add':

480 +stage the result as usual with `git add`:

481

482 ------------

483 $ git status | grep unmerged

@@ -507,12 +507,12 @@ COMMIT INFORMATION

507 Author and committer information is taken from the following environment

508 variables, if set:

509

510 - GIT_AUTHOR_NAME

511 - GIT_AUTHOR_EMAIL

512 - GIT_AUTHOR_DATE

513 - GIT_COMMITTER_NAME

514 - GIT_COMMITTER_EMAIL

515 - GIT_COMMITTER_DATE

510 + * `GIT_AUTHOR_NAME`

511 + * `GIT_AUTHOR_EMAIL`

512 + * `GIT_AUTHOR_DATE`

513 + * `GIT_COMMITTER_NAME`

514 + * `GIT_COMMITTER_EMAIL`

515 + * `GIT_COMMITTER_DATE`

516

517 (nb "<", ">" and "\n"s are stripped)

518

@@ -524,7 +524,7 @@ that, see the `credential.username` variable in linkgit:git-config[1].

524

525 In case (some of) these environment variables are not set, the information

526 is taken from the configuration items `user.name` and `user.email`, or, if not

527 -present, the environment variable EMAIL, or, if that is not set,

527 +present, the environment variable `EMAIL`, or, if that is not set,

528 system user name and the hostname used for outgoing mail (taken

529 from `/etc/mailname` and falling back to the fully qualified hostname when

530 that file does not exist).

@@ -555,7 +555,7 @@ include::i18n.txt[]

555 ENVIRONMENT AND CONFIGURATION VARIABLES

556 ---------------------------------------

557 The editor used to edit the commit log message will be chosen from the

558 -`GIT_EDITOR` environment variable, the core.editor configuration variable, the

558 +`GIT_EDITOR` environment variable, the `core.editor` configuration variable, the

559 `VISUAL` environment variable, or the `EDITOR` environment variable (in that

560 order). See linkgit:git-var[1] for details.

561

doc: apply new documentation guidelines to git commit