diff options
Diffstat (limited to 'Documentation/gitcore-tutorial.txt')
| -rw-r--r-- | Documentation/gitcore-tutorial.txt | 30 |
1 files changed, 15 insertions, 15 deletions
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 7d721c5..059c8ff 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and message, along with optionally a PGP signature that says that yes, you really did that tag. You create these annotated tags with either the `-a` or -`-s` flag to `git tag`: +`-s` flag to `git-tag`: ---------------- $ git tag -s <tagname> @@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no history outside the project you created. - if you want to move or duplicate a git repository, you can do so. There - is `git clone` command, but if all you want to do is just to + is `git-clone` command, but if all you want to do is just to create a copy of your repository (with all the full history that went along with it), you can do so with a regular `cp -a git-tutorial new-git-tutorial`. @@ -776,7 +776,7 @@ to it. ================================================ If you make the decision to start your new branch at some other point in the history than the current `HEAD`, you can do so by -just telling `git checkout` what the base of the checkout would be. +just telling `git-checkout` what the base of the checkout would be. In other words, if you have an earlier tag or branch, you'd just do ------------ @@ -819,7 +819,7 @@ $ git branch <branchname> [startingpoint] which will simply _create_ the branch, but will not do anything further. You can then later -- once you decide that you want to actually develop -on that branch -- switch to that branch with a regular `git checkout` +on that branch -- switch to that branch with a regular `git-checkout` with the branchname as the argument. @@ -881,7 +881,7 @@ source. Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want to merge the work we did on the `mybranch` branch into the `master` branch (which is currently our `HEAD` too). To do that, there's a nice -script called `git merge`, which wants to know which branches you want +script called `git-merge`, which wants to know which branches you want to resolve and what the merge is all about: ------------ @@ -1023,12 +1023,12 @@ Merging external work It's usually much more common that you merge with somebody else than merging with your own branches, so it's worth pointing out that git makes that very easy too, and in fact, it's not that different from -doing a `git merge`. In fact, a remote merge ends up being nothing +doing a `git-merge`. In fact, a remote merge ends up being nothing more than "fetch the work from a remote repository into a temporary tag" -followed by a `git merge`. +followed by a `git-merge`. Fetching from a remote repository is done by, unsurprisingly, -`git fetch`: +`git-fetch`: ---------------- $ git fetch <remote-repository> @@ -1115,7 +1115,7 @@ argument. [NOTE] You could do without using any branches at all, by keeping as many local repositories as you would like to have -branches, and merging between them with `git pull`, just like +branches, and merging between them with `git-pull`, just like you merge between branches. The advantage of this approach is that it lets you keep a set of files for each `branch` checked out and you may find it easier to switch back and forth if you @@ -1132,7 +1132,7 @@ like this: $ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/ ------------------------------------------------ -and use the "linus" keyword with `git pull` instead of the full URL. +and use the "linus" keyword with `git-pull` instead of the full URL. Examples. @@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch +* [master^] Some fun. ------------ -Remember, before running `git merge`, our `master` head was at +Remember, before running `git-merge`, our `master` head was at "Some fun." commit, while our `mybranch` head was at "Some work." commit. @@ -1345,7 +1345,7 @@ $ mkdir my-git.git ------------ Then, make that directory into a git repository by running -`git init`, but this time, since its name is not the usual +`git-init`, but this time, since its name is not the usual `.git`, we do things slightly differently: ------------ @@ -1407,7 +1407,7 @@ $ git repack will do it for you. If you followed the tutorial examples, you would have accumulated about 17 objects in `.git/objects/??/` -directories by now. `git repack` tells you how many objects it +directories by now. `git-repack` tells you how many objects it packed, and stores the packed file in `.git/objects/pack` directory. @@ -1656,8 +1656,8 @@ $ git reset --hard master~2 ------------ You can make sure 'git show-branch' matches the state before -those two 'git merge' you just did. Then, instead of running -two 'git merge' commands in a row, you would merge these two +those two 'git-merge' you just did. Then, instead of running +two 'git-merge' commands in a row, you would merge these two branch heads (this is known as 'making an Octopus'): ------------ |