温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
示例1：git commit&&-m&"提交的描述信息"如果我们这里不用-m参数的话，git将调到一个文本编译器（通常是vim）来让你输入提交的描述信息可能一天下来，你对工作树中的许多文档都进行了更新（文档添加、修改、删除），但是我忘记了它们的名字，此时若将所做的全部更新添加到索引中，比较轻省的做法就是：git commit&-a&-m&"提交的描述信息"git commit&命令的-a&选项可只将所有被修改或者已删除的且已经被git管理的文档提交倒仓库中。如果只是修改或者删除了已被Git 管理的文档，是没必要使用git add&命令的。git add&.命令除了能够判断出当前目录（包括其子目录）所有被修改或者已删除的文档，还能判断用户所添加的新文档，并将其信息追加到索引中。git commit --amend&对于已经修改提交过的注释，如果需要修改，可以借助 git commit --amend 来进行。& 例如 在framework/base 里最新的提交就是 resolving the roaming problem，我现在需要将其改为 resolving the roaming problem for fixing bug 7732& 在 framework/base 下 输入 git commit --amend,就会进入一个文本编辑界面（如下），在注释的地方修改 ，保存然后退出，这样注释就修改了，再重新push.另外，要注意的问题是，Git 不会主动记录你对文档进行的更新，除非你对它发号施令（比如通过git add命令）语法 [-a | --interactive | --patch] [-s] [-v] [-u&mode&] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) &commit&]
[-F &file& | -m &msg&] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=&author&]
[--date=&date&] [--cleanup=&mode&] [--status | --no-status]
[-i | -o] [--] [&file&…]DESCRIPTIONStores the current contents of the index in a new commit along with a log message from the user describing the changes.The content to be added can be specified in several ways:The&&option can be used to obtain a summary of what is included by any of the above for the next commit by giving the same set of parameters (options and paths).If you make a commit and then find a mistake immediately after that, you can recover from it with&.OPTIONSTell the command to automatically stage files that have been modified and deleted, but new files you have not told git about are not affected.Use the interactive patch selection interface to chose which changes to commit. See&&for details.Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit.Like&, but with&&the editor is invoked, so that the user can further edit the commit message.Construct a commit message for use with&. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See&&for details.Construct a commit message for use with&. The commit message subject line is taken from the specified commit with a prefix of "squash! ". Can be used with additional commit message options (///). See&&for details.When used with -C/-c/--amend options, or when committing after a a conflicting cherry-pick, declare that the authorship of the resulting commit now belongs of the committer. This also renews the author timestamp.When doing a dry-run, give the output in the short-format. See&&for details. Implies&.When doing a dry-run, give the output in a porcelain-ready format. See&&for details. Implies&.When showing&&or&&status output, terminate entries in the status output with NUL, instead of LF. If no format is given, implies the&&output format.Take the commit message from the given file. Use&&to read the message from the standard input.Override the commit author. Specify an explicit author using the standard&&format. Otherwise &author& is assumed to be a pattern and is used to search for an existing commit by that author (i.e. rev-list --all -i --author=&author&); the commit author is then copied from the first such commit found.Override the author date used in the commit.Use the given &msg& as the commit message.Use the contents of the given file as the initial version of the commit message. The editor is invoked and you can make subsequent changes. If a message is specified using the&&or&&options, this option has no effect. This overrides the&&configuration variable.Add Signed-off-by line by the committer at the end of the commit log message.This option bypasses the pre-commit and commit-msg hooks. See also&.Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts.Like --allow-empty this command is primarily for use by foreign SCM interface scripts. It allows you to create a commit with an empty commit message without using plumbing commands like&.This option sets how the commit message is cleaned up. The&&can be one of&,&,&, and&. The&&mode will strip leading and trailing empty lines and #commentary from the commit message only if the message is to be edited. Otherwise only whitespace removed. The&&mode does not change message at all,&&removes just leading/trailing whitespace lines and&removes both whitespace and commentary.The message taken from file with&, command line with&, and from file with&&are usually used as the commit log message unmodified. This option lets you further edit the message taken from these sources.Used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip?—?if it was a merge, it will have the parents of the current tip as parents?—?so the current top commit is discarded.It is a rough equivalent for:but can be used to amend a merge commit.You should understand the implications of rewriting history if you amend a commit that has already been published. (See the "RECOVERING FROM UPSTREAM REBASE" section in&.)Before making a commit out of staged contents so far, stage the contents of paths given on the command line as well. This is usually not what you want unless you are concluding a conflicted merge.Make a commit only from the paths specified on the command line, disregarding any contents that have been staged so far. This is the default mode of operation of&&if any paths are given on the command line, in which case this option can be omitted. If this option is specified together with&, then no paths need to be specified, which can be used to amend the last commit without committing changes that have already been staged.Show untracked files.The mode parameter is optional (defaults to&), and is used to specify the handlin when -u is not used, the default is&, i.e. show untracked files and directories.The possible options are:Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template. Note that this diff output doesn’t have its lines prefixed with&.Suppress commit summary message.Do not create a commit, but show a list of paths that are to be committed, paths with local changes that will be left uncommitted and paths that are untracked.Include the output of&&in the commit message template when using an editor to prepare the commit message. Defaults to on, but can be used to override configuration variable commit.status.Do not include the output of&&in the commit message template when using an editor to prepare the default commit message.Do not interpret any more arguments as options.When files are given on the command line, the command commits the contents of the named files, without recording the changes already staged. The contents of these files are also staged for the next commit on top of what have been staged before.The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables and the&&option support the following date formats:It is&, where&&is the number of seconds since the UNIX epoch.&&is a positive or negative offset from UTC. For example CET (which is 2 hours ahead UTC) is&.The standard email format as described by RFC 2822, for example&.Time and date specified by the ISO 8601 standard, for example&. The parser accepts a space instead of the&&character as well.NoteIn addition, the date part is accepted in the following formats:&,&&and&.EXAMPLESWhen recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the "index" with&. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with&, which effectively reverts&&and prevents the changes to this file from participating in the next commit. After building the state to be committed incrementally with these commands,&&(without any pathname parameter) is used to record what has been staged so far. This is the most basic form of the command. An example:Instead of staging files after each individual change, you can tell&&to notice the changes to the files whose contents are tracked in your working tree and do corresponding&&and&&for you. That is, this example does the same as the earlier example if there is no other change in your working tree:The command&&first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary&and&&for you.After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to&. When pathnames are given, the command makes a commit that only records the changes made to the named paths:This makes a commit that records the modification to&. The changes staged for&&and&&are not included in the resulting commit. However, their changes are not lost?—?they are still staged and merely held back. After the above sequence, if you do:this second commit would record the changes to&&and&&as expected.After a merge (initiated by&&or&) stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with&&and after fixing them manually in your working tree, you would stage the result as usual with&:After resolving conflicts and staging the result,&&would stop mentioning the conflicted path. When you are done, run&&to finally record the merge:As with the case to record your own changes, you can use&&option to save typing. One difference is that during a merge resolution, you cannot use&&with pathnames to alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command refuses to run when given pathnames (but see&&option).DISCUSSIONThough not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject: line and the rest of the commit in the body.At the core level, git is character encoding agnostic.Although we encourage that the commit log messages are encoded in UTF-8, both the core and git Porcelain are designed not to force UTF-8 on projects. If all participants of a particular project find it more convenient to use legacy encodings, git does not forbid it. However, there are a few things to keep in mind.Note that we deliberately chose not to re-code the commit log message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation.ENVIRONMENT AND CONFIGURATION VARIABLESThe editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order). See&&for details.HOOKSThis command can run&,&,&, and&&hooks. See&&for more information.SEE ALSO,&,&,&,&
阅读(6746)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'git commit简介',
blogAbstract:'翻译整理自： '
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}应用雷达-苹果App Store应用排行榜单历史跟踪查询-iPad新闻分类榜App排名-Apple应用市场苹果商店
&&&新闻付费
上升0名 总榜103名
上升0名 总榜173名
上升2名 总榜270名
下降1名总榜405名
下降1名总榜953名
上升2名 总榜997名
您还没有登录，请登录后使用此功能96202人阅读
版本控制（51）
翻译整理自：&&
在用git来进行版本控制时，我需要执行git commit命令，将索引内容添加到仓库中。
git commit&&-m&&提交的描述信息&
如果我们这里不用-m参数的话，git将调到一个文本编译器（通常是vim）来让你输入提交的描述信息
可能一天下来，你对工作树中的许多文档都进行了更新（文档添加、修改、删除），但是我忘记了它们的名字，此时若将所做的全部更新添加到索引中，比较轻省的做法就是：
git commit&-a&-m&&提交的描述信息&
git commit&命令的-a&选项可只将所有被修改或者已删除的且已经被git管理的文档提交倒仓库中。如果只是修改或者删除了已被Git
管理的文档，是没必要使用git add&命令的。
git add&.命令除了能够判断出当前目录（包括其子目录）所有被修改或者已删除的文档，还能判断用户所添加的新文档，并将其信息追加到索引中。
git commit&--amend&对于已经修改提交过的注释，如果需要修改，可以借助 git commit --amend 来进行。
&&例如 在framework/base 里最新的提交就是 resolving the roaming problem，我现在需要将其改为 resolving the roaming problem for fixing bug 7732
& 在 framework/base 下 输入 git commit --amend,就会进入一个文本编辑界面（如下），在注释的地方修改 ，保存然后退出，这样注释就修改了，再重新push.
另外，要注意的问题是，Git 不会主动记录你对文档进行的更新，除非你对它发号施令（比如通过git add命令）
[-a | --interactive | --patch] [-s] [-v] [-u&mode&] [--amend] [--dry-run] [(-c | -C | --fixup | --squash) &commit&] [-F &file& | -m &msg&] [--reset-author]
[--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=&author&] [--date=&date&] [--cleanup=&mode&] [--status | --no-status] [-i | -o] [--] [&file&…]
DESCRIPTION
Stores the current contents of the index in a new commit along with a log message from the user describing the changes.
The content to be added can be specified in several ways:
The&&option can be used to obtain a summary of what is included by any of the above for the next commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after that, you can recover from it with&.
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told git about are not affected.
Use the interactive patch selection interface to chose which changes to commit. See&&for
Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit.
Like&, but with&&the editor is invoked, so that the user can further edit the commit message.
Construct a commit message for use with&. The commit message will be the subject line from the specified commit with a prefix of &fixup! &. See&&for
Construct a commit message for use with&. The commit message subject line is taken from the specified commit with a prefix of &squash! &. Can be used with additional commit message options (///).
See&&for details.
When used with -C/-c/--amend options, or when committing after a a conflicting cherry-pick, declare that the authorship of the resulting commit now belongs of the committer. This also renews the author timestamp.
When doing a dry-run, give the output in the short-format. See&&for
details. Implies&.
When doing a dry-run, give the output in a porcelain-ready format. See&&for
details. Implies&.
When showing&&or&&status output, terminate entries in the status output with NUL, instead of LF. If no format is given, implies the&&output
Take the commit message from the given file. Use&&to read the message from the standard input.
Override the commit author. Specify an explicit author using the standard&&format.
Otherwise &author& is assumed to be a pattern and is used to search for an existing commit by that author (i.e. rev-list --all -i --author=&author&); the commit author is then copied from the first such commit found.
Override the author date used in the commit.
Use the given &msg& as the commit message.
Use the contents of the given file as the initial version of the commit message. The editor is invoked and you can make subsequent changes. If a message is specified using the&&or&&options,
this option has no effect. This overrides the&&configuration variable.
Add Signed-off-by line by the committer at the end of the commit log message.
This option bypasses the pre-commit and commit-msg hooks. See also&.
Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts.
Like --allow-empty this command is primarily for use by foreign SCM interface scripts. It allows you to create a commit with an empty commit message without using plumbing commands like&.
This option sets how the commit message is cleaned up. The&&can be one of&,&,&,
and&. The&&mode will strip leading and trailing empty lines and #commentary from the commit message only if the message is to
be edited. Otherwise only whitespace removed. The&&mode does not change message at all,&&removes just leading/trailing whitespace
lines and&removes both whitespace and commentary.
The message taken from file with&, command line with&, and from file with&&are usually used as the commit log message
unmodified. This option lets you further edit the message taken from these sources.
Used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current
branch. The commit you create replaces the current tip?—?if it was a merge, it will have the parents of the current tip as parents?—?so the current top commit is discarded.
It is a rough equivalent for:
but can be used to amend a merge commit.
You should understand the implications of rewriting history if you amend a commit that has already been published. (See the &RECOVERING FROM UPSTREAM REBASE& section in&.)
Before making a commit out of staged contents so far, stage the contents of paths given on the command line as well. This is usually not what you want unless you are concluding a conflicted merge.
Make a commit only from the paths specified on the command line, disregarding any contents that have been staged so far. This is the default mode of operation of&&if any paths are given on
the command line, in which case this option can be omitted. If this option is specified together with&, then no paths need to be specified, which can be used to amend the last commit without
committing changes that have already been staged.
Show untracked files.
The mode parameter is optional (defaults to&), and is used to specify the handlin when -u is not used, the default is&,
i.e. show untracked files and directories.
The possible options are:
Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template. Note that this diff output doesn’t have its lines prefixed with&.
Suppress commit summary message.
Do not create a commit, but show a list of paths that are to be committed, paths with local changes that will be left uncommitted and paths that are untracked.
Include the output of&&in the commit message template
when using an editor to prepare the commit message. Defaults to on, but can be used to override configuration variable commit.status.
Do not include the output of&&in the commit message
template when using an editor to prepare the default commit message.
Do not interpret any more arguments as options.
When files are given on the command line, the command commits the contents of the named files, without recording the changes already staged. The contents of these files are also staged for the next commit on top of what have been staged before.
The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables and the&&option support the following date formats:
It is&, where&&is the number of seconds since the UNIX epoch.&&is
a positive or negative offset from UTC. For example CET (which is 2 hours ahead UTC) is&.
The standard email format as described by RFC 2822, for example&.
Time and date specified by the ISO 8601 standard, for example&. The parser accepts a space instead of the&&character as well.
In addition, the date part is accepted in the following formats:&,&&and&.
When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the &index& with&. A file can be reverted back, only in the index
but not in the working tree, to that of the last commit with&, which effectively reverts&&and prevents the changes to this
file from participating in the next commit. After building the state to be committed incrementally with these commands,&&(without any pathname parameter) is used to record what has been staged so far.
This is the most basic form of the command. An example:
Instead of staging files after each individual change, you can tell&&to notice the changes to the files whose contents are tracked in your working tree and do corresponding&&and&&for you. That is, this example does the same as the earlier example if there is no other change in your working tree:
The command&&first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary&and&&for you.
After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to&. When pathnames are given, the command makes a commit that only records the changes made
to the named paths:
This makes a commit that records the modification to&. The changes staged for&&and&&are not included
in the resulting commit. However, their changes are not lost?—?they are still staged and merely held back. After the above sequence, if you do:
this second commit would record the changes to&&and&&as expected.
After a merge (initiated by&&or&) stops because of conflicts, cleanly merged paths are already staged to be committed for
you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with&&and after fixing them manually in your working tree, you would stage
the result as usual with&:
After resolving conflicts and staging the result,&&would stop mentioning the conflicted path. When you are done, run&&to finally record the
As with the case to record your own changes, you can use&&option to save typing. One difference is that during a merge resolution, you cannot use&&with pathnames
to alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command refuses to run when given pathnames (but see&&option).
DISCUSSION
Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the
first line on the Subject: line and the rest of the commit in the body.
At the core level, git is character encoding agnostic.
Although we encourage that the commit log messages are encoded in UTF-8, both the core and git Porcelain are designed not to force UTF-8 on projects. If all participants of a particular project find it more convenient to use legacy encodings, git does not forbid
it. However, there are a few things to keep in mind.
Note that we deliberately chose not to re-code the commit log message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation.
ENVIRONMENT AND CONFIGURATION VARIABLES
The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order). See&&for
This command can run&,&,&, and&&hooks.
See&&for more information.
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：5275227次
积分：33963
积分：33963
排名：第131名
原创：216篇
转载：405篇
译文：178篇
评论：409条
(1)(3)(3)(1)(1)(2)(5)(1)(1)(5)(53)(31)(60)(2)(8)(2)(6)(1)(2)(1)(7)(3)(7)(7)(7)(8)(7)(21)(44)(7)(8)(33)(17)(248)(97)(88)(1)