This will again prompt you for a message describing the change, and then
record a new version of the project.
-Alternatively, instead of running `git add` beforehand, you can use
+Alternatively, instead of running `git-add` beforehand, you can use
------------------------------------------------
$ git commit -a
Many revision control systems provide an "add" command that tells the
system to start tracking changes to a new file. Git's "add" command
-does something simpler and more powerful: `git add` is used both for new
+does something simpler and more powerful: `git-add` is used both for new
and newly modified files, and in both cases it takes a snapshot of the
given files and stages that content in the index, ready for inclusion in
the next commit.
------------------------------------------------
With this, Alice can perform the first operation alone using the
-"git fetch" command without merging them with her own branch,
+"git-fetch" command without merging them with her own branch,
using:
-------------------------------------
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with `git remote`, what was
+remote repository shorthand set up with `git-remote`, what was
fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-----------------
Git history is represented as a series of interrelated commits. We
-have already seen that the git log command can list those commits.
+have already seen that the git-log command can list those commits.
Note that first line of each git log entry also gives a name for the
commit:
merge-base: Clarify the comments on post processing.
-------------------------------------
-We can give this name to git show to see the details about this
+We can give this name to git-show to see the details about this
commit.
-------------------------------------
You can also give commits names of your own; after running
-------------------------------------
-$ git-tag v2.5 1b2e1d63ff
+$ git tag v2.5 1b2e1d63ff
-------------------------------------
you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
-commits, they will be lost. Also, don't use "git reset" on a
+commits, they will be lost. Also, don't use "git-reset" on a
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
If you need to undo changes that you have pushed, use linkgit:git-revert[1]
instead.
-The git grep command can search for strings in any version of your
+The git-grep command can search for strings in any version of your
project, so
-------------------------------------
searches for all occurrences of "hello" in v2.5.
-If you leave out the commit name, git grep will search any of the
+If you leave out the commit name, git-grep will search any of the
files it manages in your current directory. So
-------------------------------------
is a quick way to search just the files that are tracked by git.
Many git commands also take sets of commits, which can be specified
-in a number of ways. Here are some examples with git log:
+in a number of ways. Here are some examples with git-log:
-------------------------------------
$ git log v2.5..v2.6 # commits between v2.5 and v2.6
# Makefile
-------------------------------------
-You can also give git log a "range" of commits where the first is not
+You can also give git-log a "range" of commits where the first is not
necessarily an ancestor of the second; for example, if the tips of
the branches "stable-release" and "master" diverged from a common
commit some time ago, then
will show the list of commits made on the stable branch but not
the experimental branch.
-The "git log" command has a weakness: it must present commits in a
+The "git-log" command has a weakness: it must present commits in a
list. When the history has lines of development that diverged and
-then merged back together, the order in which "git log" presents
+then merged back together, the order in which "git-log" presents
those commits is meaningless.
Most projects with multiple contributors (such as the linux kernel,
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
-You can also use "git show" to see any such file:
+You can also use "git-show" to see any such file:
-------------------------------------
$ git show v2.5:Makefile
projects / thirdparty / git.git / blobdiff