mirror of https://github.com/zulip/zulip.git
docs: Fix Git capitalization.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
parent
f244c2eca4
commit
503127c2e9
|
@ -31,7 +31,7 @@ We also highly recommend the following:
|
|||
|
||||
## Get a graphical client
|
||||
|
||||
Even if you're comfortable using git on the command line, having a graphical
|
||||
Even if you're comfortable using Git on the command line, having a graphical
|
||||
client can be useful for viewing your repository. This is especially true
|
||||
when doing complicated rebases and similar operations because you can check
|
||||
the state of your repository after each command to see what changed. If
|
||||
|
|
|
@ -4,7 +4,7 @@ Git is a powerful yet complex version control system. Even for contributors
|
|||
experienced at using version control, it can be confusing. The good news is
|
||||
that nearly all Git actions add information to the Git database, rather than
|
||||
removing it. As such, it's hard to make Git perform actions that you can't
|
||||
undo. However, git can't undo what it doesn't know about, so it's a good
|
||||
undo. However, Git can't undo what it doesn't know about, so it's a good
|
||||
practice to frequently commit your changes and frequently push your commits to
|
||||
your remote repository.
|
||||
|
||||
|
@ -59,7 +59,7 @@ e5f8211 HEAD@{0}: pull upstream main: Merge made by the 'recursive' strategy.
|
|||
13bea0e HEAD@{1}: commit: test commit for docs.
|
||||
```
|
||||
|
||||
Reflog output will be long. The most recent git refs will be listed at the top.
|
||||
Reflog output will be long. The most recent Git refs will be listed at the top.
|
||||
In the example above `e5f8211 HEAD@{0}:` is the merge commit made automatically
|
||||
by `git pull` and `13bea0e HEAD@{1}:` is the last commit I made before running
|
||||
`git pull`, the commit that I want to rollback to.
|
||||
|
@ -81,7 +81,7 @@ committed, use `git reset --merge <commit>` instead.
|
|||
:::
|
||||
|
||||
You can also use the relative reflog `HEAD@{1}` instead of the commit hash,
|
||||
just keep in mind that this changes as you run git commands.
|
||||
just keep in mind that this changes as you run Git commands.
|
||||
|
||||
Now when you look at the output of `git reflog`, you should see that the tip of your branch points to your
|
||||
last commit `13bea0e` before the merge:
|
||||
|
@ -145,10 +145,10 @@ $ git cherry-pick 67aea58
|
|||
create mode 100644 test4.txt
|
||||
```
|
||||
|
||||
## Recover from a git rebase failure
|
||||
## Recover from a `git rebase` failure
|
||||
|
||||
One situation in which `git rebase` will fail and require you to intervene is
|
||||
when your change, which git will try to re-apply on top of new commits from
|
||||
when your change, which Git will try to re-apply on top of new commits from
|
||||
which ever branch you are rebasing on top of, is to code that has been changed
|
||||
by those new commits.
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
## Know what branch you're working on
|
||||
|
||||
When using Git, it's important to know which branch you currently have checked
|
||||
out because most git commands implicitly operate on the current branch. You can
|
||||
out because most Git commands implicitly operate on the current branch. You can
|
||||
determine the currently checked out branch several ways.
|
||||
|
||||
One way is with [git status][gitbook-git-status]:
|
||||
|
@ -44,7 +44,7 @@ You can also configure [Bash][gitbook-other-envs-bash] and
|
|||
You'll want to [keep your fork][github-help-sync-fork] up-to-date with changes
|
||||
from Zulip's main repositories.
|
||||
|
||||
**Note about git pull**: You might be used to using `git pull` on other
|
||||
**Note about `git pull`**: You might be used to using `git pull` on other
|
||||
projects. With Zulip, because we don't use merge commits, you'll want to avoid
|
||||
it. Rather than using `git pull`, which by default is a shortcut for
|
||||
`git fetch && git merge FETCH_HEAD` ([docs][gitbook-git-pull]), you
|
||||
|
@ -164,7 +164,7 @@ Untracked files:
|
|||
nothing added to commit but untracked files present (use "git add" to track)
|
||||
```
|
||||
|
||||
### Stage additions with git add
|
||||
### Stage additions with `git add`
|
||||
|
||||
To add changes to your staging area, use `git add <filename>`. Because
|
||||
`git add` is all about staging the changes you want to commit, you use
|
||||
|
@ -212,7 +212,7 @@ Untracked files:
|
|||
nothing added to commit but untracked files present (use "git add" to track)
|
||||
```
|
||||
|
||||
### Stage deletions with git rm
|
||||
### Stage deletions with `git rm`
|
||||
|
||||
To remove existing files from your repository, use `git rm`
|
||||
([documentation][gitbook-rm]). This command can either stage the file for
|
||||
|
@ -264,7 +264,7 @@ $ git reset HEAD test2.txt
|
|||
|
||||
Unfortunately, you can't restore a file deleted with `git rm` if you didn't use
|
||||
the `--cache` option. However, `git rm` only deletes files it knows about.
|
||||
Files you have never added to git won't be deleted.
|
||||
Files you have never added to Git won't be deleted.
|
||||
|
||||
## Commit changes
|
||||
|
||||
|
@ -349,7 +349,7 @@ To git@github.com:christi3k/zulip.git
|
|||
* [new branch] issue-demo -> issue-demo
|
||||
```
|
||||
|
||||
If you want to see what git will do without actually performing the push, add
|
||||
If you want to see what Git will do without actually performing the push, add
|
||||
the `-n` (dry-run) option: `git push -n origin <branch-name>`. If everything
|
||||
looks good, re-run the push command without `-n`.
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ you a lot of time, by automatically detecting linter errors as you
|
|||
make them.
|
||||
:::
|
||||
|
||||
**Note:** The linters only check files that git tracks. Remember to `git add`
|
||||
**Note:** The linters only check files that Git tracks. Remember to `git add`
|
||||
new files before running lint checks.
|
||||
|
||||
Our linting tools generally support the ability to lint files
|
||||
|
|
|
@ -504,7 +504,7 @@ unfortunately give up some type safety by falling back to
|
|||
## Troubleshooting advice
|
||||
|
||||
All of our linters, including mypy, are designed to only check files
|
||||
that have been added in git (this is by design, since it means you
|
||||
that have been added in Git (this is by design, since it means you
|
||||
have untracked files in your Zulip checkout safely). So if you get a
|
||||
`mypy` error like this after adding a new file that is referenced by
|
||||
the existing codebase:
|
||||
|
|
|
@ -93,7 +93,7 @@ class BaseDocumentationSpider(scrapy.Spider):
|
|||
if url.startswith(ZULIP_SERVER_GITHUB_FILE_URL_PREFIX) or url.startswith(
|
||||
ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX
|
||||
):
|
||||
# We can verify these links directly in the local git repo without making any requests to GitHub servers.
|
||||
# We can verify these links directly in the local Git repo without making any requests to GitHub servers.
|
||||
return False
|
||||
if "github.com/zulip" in url:
|
||||
# We want to check these links but due to rate limiting from GitHub, these checks often
|
||||
|
|
|
@ -166,7 +166,7 @@ def need_to_run_build_timezone_data() -> bool:
|
|||
|
||||
def need_to_run_compilemessages() -> bool:
|
||||
if not os.path.exists("locale/language_name_map.json"):
|
||||
# User may have cleaned their git checkout.
|
||||
# User may have cleaned their Git checkout.
|
||||
print("Need to run compilemessages due to missing language_name_map.json")
|
||||
return True
|
||||
|
||||
|
|
Loading…
Reference in New Issue