Git远程操作详解 - 阮一峰的网络日志
Git远程操作详解
是目前最流行的，学会Git几乎成了开发者的必备技能。
Git有很多优势，其中之一就是远程操作非常简便。本文详细介绍5个Git命令，它们的概念和用法，理解了这些内容，你就会完全掌握Git远程操作。
git remote
本文针对初级用户，从最简单的讲起，但是需要读者对Git的基本用法有所了解。同时，本文覆盖了上面5个命令的几乎所有的常用用法，所以对于熟练用户也有参考价值。
一、git clone
远程操作的第一步，通常是从远程主机克隆一个版本库，这时就要用到git clone命令。
$ git clone
比如，克隆jQuery的版本库。
$ git clone /jquery/jquery.git
该命令会在本地主机生成一个目录，与远程主机的版本库同名。如果要指定不同的目录名，可以将目录名作为git clone命令的第二个参数。
$ git clone
git clone支持多种协议，除了HTTP(s)以外，还支持SSH、Git、本地文件协议等，下面是一些例子。
$ git clone http[s]:///path/to/repo.git/
$ git clone ssh:///path/to/repo.git/
$ git clone git:///path/to/repo.git/
$ git clone /opt/git/project.git
$ git clone file:///opt/git/project.git
$ git clone ftp[s]:///path/to/repo.git/
$ git clone rsync:///path/to/repo.git/
SSH协议还有另一种写法。
$ git clone [user@]:path/to/repo.git/
通常来说，Git协议下载速度最快，SSH协议用于需要用户认证的场合。各种协议优劣的详细讨论请参考。
二、git remote
为了便于管理，Git要求每个远程主机都必须指定一个主机名。git remote命令就用于管理主机名。
不带选项的时候，git remote命令列出所有远程主机。
$ git remote
使用-v选项，可以参看远程主机的网址。
$ git remote -v
:jquery/jquery.git (fetch)
:jquery/jquery.git (push)
上面命令表示，当前只有一台远程主机，叫做origin，以及它的网址。
克隆版本库的时候，所使用的远程主机自动被Git命名为origin。如果想用其他的主机名，需要用git clone命令的-o选项指定。
$ git clone -o jQuery /jquery/jquery.git
$ git remote
上面命令表示，克隆的时候，指定远程主机叫做jQuery。
git remote show命令加上主机名，可以查看该主机的详细信息。
$ git remote show
git remote add命令用于添加远程主机。
$ git remote add
git remote rm命令用于删除远程主机。
$ git remote rm
git remote rename命令用于远程主机的改名。
$ git remote rename
三、git fetch
一旦远程主机的版本库有了更新（Git术语叫做commit），需要将这些更新取回本地，这时就要用到git fetch命令。
$ git fetch
上面命令将某个远程主机的更新，全部取回本地。
git fetch命令通常用来查看其他人的进程，因为它取回的代码对你本地的开发代码没有影响。
默认情况下，git fetch取回所有分支（branch）的更新。如果只想取回特定分支的更新，可以指定分支名。
$ git fetch
比如，取回origin主机的master分支。
$ git fetch origin master
所取回的更新，在本地主机上要用"远程主机名/分支名"的形式读取。比如origin主机的master，就要用origin/master读取。
git branch命令的-r选项，可以用来查看远程分支，-a选项查看所有分支。
$ git branch -r
origin/master
$ git branch -a
remotes/origin/master
上面命令表示，本地主机的当前分支是master，远程分支是origin/master。
取回远程主机的更新以后，可以在它的基础上，使用git checkout命令创建一个新的分支。
$ git checkout -b newBrach origin/master
上面命令表示，在origin/master的基础上，创建一个新分支。
此外，也可以使用git merge命令或者git rebase命令，在本地分支上合并远程分支。
$ git merge origin/master
$ git rebase origin/master
上面命令表示在当前分支上，合并origin/master。
四、git pull
git pull命令的作用是，取回远程主机某个分支的更新，再与本地的指定分支合并。它的完整格式稍稍有点复杂。
$ git pull
比如，取回origin主机的next分支，与本地的master分支合并，需要写成下面这样。
$ git pull origin next:master
如果远程分支是与当前分支合并，则冒号后面的部分可以省略。
$ git pull origin next
上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再做git merge。
$ git fetch origin
$ git merge origin/next
在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系（tracking）。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动"追踪"origin/master分支。
Git也允许手动建立追踪关系。
git branch --set-upstream master origin/next
上面命令指定master分支追踪origin/next分支。
如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。
$ git pull origin
上面命令表示，本地的当前分支自动与对应的origin主机"追踪分支"（remote-tracking branch）进行合并。
如果当前分支只有一个追踪分支，连远程主机名都可以省略。
$ git pull
上面命令表示，当前分支自动与唯一一个追踪分支进行合并。
如果合并需要采用rebase模式，可以使用--rebase选项。
$ git pull --rebase
如果远程主机删除了某个分支，默认情况下，git pull 不会在拉取远程分支的时候，删除对应的本地分支。这是为了防止，由于其他人操作了远程主机，导致git pull不知不觉删除了本地分支。
但是，你可以改变这个行为，加上参数 -p 就会在本地删除远程已经删除的分支。
$ git pull -p
# 等同于下面的命令
$ git fetch --prune origin
$ git fetch -p
五、git push
git push命令用于将本地分支的更新，推送到远程主机。它的格式与git pull命令相仿。
$ git push
注意，分支推送顺序的写法是&来源地>:&目的地>，所以git pull是&远程分支>:&本地分支>，而git push是&本地分支>:&远程分支>。
如果省略远程分支名，则表示将本地分支推送与之存在"追踪关系"的远程分支（通常两者同名），如果该远程分支不存在，则会被新建。
$ git push origin master
上面命令表示，将本地的master分支推送到origin主机的master分支。如果后者不存在，则会被新建。
如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支。
$ git push origin :master
$ git push origin --delete master
上面命令表示删除origin主机的master分支。
如果当前分支与远程分支之间存在追踪关系，则本地分支和远程分支都可以省略。
$ git push origin
上面命令表示，将当前分支推送到origin主机的对应分支。
如果当前分支只有一个追踪分支，那么主机名都可以省略。
$ git push
如果当前分支与多个主机存在追踪关系，则可以使用-u选项指定一个默认主机，这样后面就可以不加任何参数使用git push。
$ git push -u origin master
上面命令将本地的master分支推送到origin主机，同时指定origin为默认主机，后面就可以不加任何参数使用git push了。
不带任何参数的git push，默认只推送当前分支，这叫做simple方式。此外，还有一种matching方式，会推送所有有对应的远程分支的本地分支。Git 2.0版本之前，默认采用matching方法，现在改为默认采用simple方式。如果要修改这个设置，可以采用git config命令。
$ git config --global push.default matching
$ git config --global push.default simple
还有一种情况，就是不管是否存在对应的远程分支，将本地的所有分支都推送到远程主机，这时需要使用--all选项。
$ git push --all origin
上面命令表示，将所有本地分支都推送到origin主机。
如果远程主机的版本比本地版本更新，推送时Git会报错，要求先在本地做git pull合并差异，然后再推送到远程主机。这时，如果你一定要推送，可以使用--force选项。
$ git push --force origin
上面命令使用--force选项，结果导致远程主机上更新的版本被覆盖。除非你很确定要这样做，否则应该尽量避免使用--force选项。
最后，git push不会推送标签（tag），除非使用--tags选项。
$ git push origin --tags
编程免不了要写配置文件，怎么写配置也是一门学问。
谷歌和 Facebook 都只有一个代码仓库，全公司的代码都放在这个库里。
学过网页开发就会知道，CSS 不能算编程语言，只是网页样式的一种描述方法。
上一篇文章，我介绍了 Systemd 的主要命令，今天介绍如何使用它完成一些基本的任务。116102人阅读
版本控制（46）
git merge的基本用法为把一个分支或或某个commit的修改合并现在的分支上。
我们可以运行git
merge -h和git
merge --help查看其命令，后者会直接转到一个网页（git的帮助文档），更详细。
usage:&git&merge&[options] [&commit&...]
&& or:&git merge&[options] &msg& HEAD &commit&
&& or:&git merge&--abort
&&&&-n&&&&&&&&&&&&&&&&&&& do not show a diffstat at the end of the merge
&&& --stat&&&&&&&&&&&&&&& show a diffstat at the end of the merge
&&& --summary&&&&&&&&&&&& (synonym to --stat)
&&& --log[=&n&]&&&&&&&&&& add (at most &n&) entries from shortlog to merge commi&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& t message
&&&&--squash&&&&&&&&&&&&& create a single commit instead of doing a merge
&&&&--commit&&&&&&&&&&&&& perform a commit if the merge succeeds (default)
&&& -e, --edit&&&&&&&&&&& edit message before committing
&&& --ff&&&&&&&&&&&&&&&&& allow fast-forward (default)
&&& --ff-only&&&&&&&&&&&& abort if fast-forward is not possible
&&& --rerere-autoupdate&& update the index with reused conflict resolution if po&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ssible
&&& -s, --strategy &strategy&
&&&&&&&&&&&&&&&&&&&&&&&&& merge strategy to use
&&& -X, --strategy-option &option=value&
&&&&&&&&&&&&&&&&&&&&&&&&& option for selected merge strategy
&&& -m, --message &message&
&&&&&&&&&&&&&&&&&&&&&&&&& merge commit message (for a non-fast-forward merge)
&&& -v, --verbose&&&&&&&& be more verbose
&&& -q, --quiet&&&&&&&&&& be more quiet
&&& --abort&&&&&&&&&&&&&& abort the current in-progress merge
&&& --progress&&&&&&&&&&& force progress reporting
&&& -S, --gpg-sign[=&key id&]
&&&&&&&&&&&&&&&&&&&&&&&&& GPG sign commit
&&& --overwrite-ignore&&& update ignored files (default)
git merge&[options]&&msg&&HEAD&&commit&&这里的&HEAD&其实就是分支名，用于说明把&HEAD&&分支合并到当前分支。
--squash选项的含义是：本地文件内容与不使用该选项的合并结果相同，但是不保留待合并分支上的历史信息，也不提交、不移动HEAD，因此需要一条额外的commit命令。其效果相当于将another分支上的多个commit合并成一个，放在当前分支上，原来的commit历史则没有拿过来。
& &判断是否使用--squash选项最根本的标准是，待合并分支上的历史是否有意义。
如果在开发分支上提交非常随意，甚至写成微博体，那么一定要使用--squash选项。版本历史记录的应该是代码的发展，而不是开发者在编码时的活动。
只有在开发分支上每个commit都有其独自存在的意义，并且能够编译通过的情况下（能够通过测试就更完美了），才应该选择缺省的合并方式来保留commit历史。
Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an annotated (and possibly signed) tag.&
我们在将Develop分支发布到Master分支时，可能采用如下的命令：
　　# 切换到Master分支
　　git checkout master
　　# 对Develop分支进行合并
　　git merge --no-ff develop
这里稍微解释一下，上一条命令的--no-ff参数是什么意思。
这个命令要通过git
merge --help查看其命令，后者会直接转到一个网页，才能看到其详细说明
默认情况下，Git执行&快进式合并&（fast-farward merge），会直接将Master分支指向Develop分支。
git checkout master
git merge robin_local
&使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《》。
git checkout master
git merge robin_local
以下是一篇来自于哈佛大学关于git merge的文章
英文地址：
After you have finished implementing a new feature on a branch, you want to bring that new feature into the main branch, so that everyone can use it. You can do so with the&git merge&or&git
pull&command.
The syntax for the commands is as follows:
git merge [head]&
git pull . [head]
They are identical in result. (Though the&merge&form seems simpler for now, the reason for the&pull&form will become apparent when discussing multiple
developers.)
These commands perform the following operations. Let the current head be called&current, and the head to be merged calledmerge.
Identify the common ancestor of&current&and&merge. Call it&ancestor-commit.Deal with the easy cases. If the&ancestor-commit&equals&merge, then do nothing. If&ancestor-commit&equals&current,
then do a&fast forward merge.Otherwise, determine the changes between the&ancestor-commit&and&merge.Attempt to merge those changes into the files in&current.If there were no conflicts, create a new commit, with two parents,&current&and&merge. Set&current&(and&HEAD)
to point to this new commit, and update the working files for the project accordingly.If there was a conflict, insert appropriate conflict markers and inform the user. No commit is created.
Important note: Git can get very confused if there are uncommitted changes in the files when you ask it to perform a merge. So make sure to commit whatever changes you have made so far before you merge.
So, to complete the above example, say you check out the&master&head again and finish writing up the new data for your paper. Now you want to bring in those changes you made to the headers.
The repository looks like this:
& & & & &+---------- (D)
& & & & / & & & & & & |
(A) -- (B) -- (C) -------------- (E)
& & & & & & & & & & & | & & & & & |
& & & & & & & & &fix-headers & &master
& & & & & & & & & & & & & & & & & |
& & & & & & & & & & & & & & & & &HEAD
where (E) is the commit reflecting the completed version with the new data.
You would run:
git merge fix-headers
If there are no conflicts, the resulting respository looks like this:
& & & & &+---------- (D) ---------------+
& & & & / & & & & & & | & & & & & & & & &\
(A) -- (B) -- (C) -------------- (E) -- (F)
& & & & & & & & & & & | & & & & & & & & &|
& & & & & & & & &fix-headers & & & & & master
& & & & & & & & & & & & & & & & & & & & &|
& & & & & & & & & & & & & & & & & & & & HEAD
The merge commit is (F), having parents (D) and (E). Because (B) is the common ancestor between (D) and (E), the files in (F) should contain the changes between (B) and (D), namely the heading fixes, incorporated into the files from (E).
Note on terminology: When I say “merge head A&into&head B,” I mean that head B is the current head, and you are drawing changes from head A into it. Head B nothing is
done to head A. (If you replace the word “merge” with the word “pull,” it may make more sense.)
Resolving Conflicts
A conflict arises if the commit to be merged in has a change in one place, and the current commit has a change in the same place. Git has no way of telling which change should take precedence.
To resolve the commit, edit the files to fix the conflicting changes. Then run&git add&to add the resolved files, and rungit commit&to commit the repaired
merge. Git remembers that you were in the middle of a merge, so it sets the parents of the commit correctly.
如果没有冲突的话，merge完成。有冲突的话，git会提示那个文件中有冲突，比如有如下冲突：
&&&&&&& HEAD:test.c
printf (“test1″);
printf (“test2″);
&&&&&&& issueFix:test.c
可以看到 ======= 隔开的上半部分，是 HEAD（即 master 分支，在运行 merge 命令时检出的分支）中的内容，下半部分是在 issueFix 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
printf (“test2″);
这个解决方案各采纳了两个分支中的一部分内容，而且删除了 &&&&&&&，=======，和&&&&&&& 这些行。
在解决了所有文件里的所有冲突后，运行git add 将把它们标记为已解决（resolved）。
然后使用git commit命令进行提交，merge就算完成了
Fast Forward Merges
A fast forward merge is a simple optimization for merging. Say your repository looks like this:
& & & & & & +-- (D) ------ (E)
& & & & & & & &/ & & & & & &|
(A) -- (B) -- (C) & & & & & |
& & & & & & & &| & & & & & &|
& & & & & & current & & to-merge
& & & & & & & &|
& & & & & & & HEAD
and you run&git merge&to-merge. In this case, all Git needs to do is set&current&to
point to (E). Since (C) is the common ancestor, there are no changes to actually “merge.”
Hence, the resulting merged repository looks like:
& & & & & & & & +-- (D) -- (E)
& & & & & & & &/ & & & & & &|
(A) -- (B) -- (C) & & & & & |
& & & & & & & & & & & & & & |
& & & & & & & & & & to-merge, current
& & & & & & & & & & & & & & & & &|
& & & & & & & & & & & & & & & & HEAD
That is,&to-merge&and&current&both point to commit (E), and&HEAD&still points to&current.
Note an important difference: no new commit object is created for the merge. Git only shifts the head pointers around.
Common Merge Use Patterns
There are two common reasons to merge two branches. The first, as explained above, is to draw the changes from a new feature branch into the main branch.
The second use pattern is to draw the main branch into a feature branch you are developing. This keeps the feature branch up to date with the latest bug fixes and new features added to the main branch. Doing this regularly reduces the risk of creating a conflict
when you merge your feature into the main branch.
One disadvantage of doing the above is that your feature branch will end up with a lot of merge commits. An alternative that solves this problem is&,
although that comes with problems of its own.
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3623041次
积分：28132
积分：28132
排名：第132名
原创：217篇
转载：376篇
译文：178篇
评论：341条
(1)(5)(53)(31)(60)(2)(8)(2)(6)(1)(2)(1)(7)(3)(7)(7)(7)(8)(7)(21)(45)(7)(8)(33)(17)(248)(97)(88)(1)74303人阅读
版本控制（46）
翻译整理自：&&
在用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网站的观点或立场
访问：3623043次
积分：28132
积分：28132
排名：第132名
原创：217篇
转载：376篇
译文：178篇
评论：341条
(1)(5)(53)(31)(60)(2)(8)(2)(6)(1)(2)(1)(7)(3)(7)(7)(7)(8)(7)(21)(45)(7)(8)(33)(17)(248)(97)(88)(1)