NAME
----
-gitworkflows - An overview of recommended workflows with git
+gitworkflows - An overview of recommended workflows with Git
SYNOPSIS
--------
+[verse]
git *
beginning. It is always easier to squash a few commits together than
to split one big commit into several. Don't be afraid of making too
small or imperfect steps along the way. You can always go back later
-and edit the commits with `git rebase \--interactive` before you
-publish them. You can use `git stash save \--keep-index` to run the
+and edit the commits with `git rebase --interactive` before you
+publish them. You can use `git stash push --keep-index` to run the
test suite independent of other uncommitted changes; see the EXAMPLES
section of linkgit:git-stash[1].
.Release tagging
[caption="Recipe: "]
=====================================
-`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
+`git tag -s -m "Git X.Y.Z" vX.Y.Z master`
=====================================
-You need to push the new tag to a public git server (see
+You need to push the new tag to a public Git server (see
"DISTRIBUTED WORKFLOWS" below). This makes the tag available to
others tracking your project. The push could also trigger a
post-update hook to perform release-related items such as building
* linkgit:git-pull[1] that does fetch and merge in one go.
-Note the last point. Do 'not' use 'git-pull' unless you actually want
+Note the last point. Do 'not' use 'git pull' unless you actually want
to merge the remote branch.
Getting changes out is easy:
<url> <branch>
-------------------------------------
-In that case, 'git-pull' can do the fetch and merge in one go, as
+In that case, 'git pull' can do the fetch and merge in one go, as
follows.
.Push/pull: Merging remote topics
`git pull <url> <branch>`
=====================================
-Occasionally, the maintainer may get merge conflicts when he tries to
-pull changes from downstream. In this case, he can ask downstream to
+Occasionally, the maintainer may get merge conflicts when they try to
+pull changes from downstream. In this case, they can ask downstream to
do the merge and resolve the conflicts themselves (perhaps they will
know better how to resolve them). It is one of the rare cases where
downstream 'should' merge from upstream.
If you receive such a patch series (as maintainer, or perhaps as a
reader of the mailing list it was sent to), save the mails to files,
-create a new topic branch and use 'git-am' to import the commits:
+create a new topic branch and use 'git am' to import the commits:
.format-patch/am: Importing patches
[caption="Recipe: "]
GIT
---
-Part of the linkgit:git[1] suite.
+Part of the linkgit:git[1] suite