fix #29

2026-04-13 17:51:58 +08:00 · 2017-03-15 01:06:03 +08:00
parent 11a247eb7d
commit 1cb36c03cd
5 changed files with 24 additions and 24 deletions
--- a/git-workflows-and-tutorials/pull-request.md
+++ b/git-workflows-and-tutorials/pull-request.md
@@ -162,7 +162,7 @@ git checkout -b some-feature
 git commit -a -m "Add first draft of some feature"
 ```

-在新功能分支上，小红按需要添加提交。甚至如果小红觉得功能分支上的提交历史太乱了，她可以用[交互式`rebase`](https://www.atlassian.com/git/tutorial/rewriting-git-history#!rebase-i)来删除或压制提交。
+在新功能分支上，小红按需要添加提交。甚至如果小红觉得功能分支上的提交历史太乱了，她可以用[交互式`rebase`](https://www.atlassian.com/git/tutorials/rewriting-history#git-rebase-i)来删除或压制提交。
 对于大型项目，整理功能分支的历史可以让项目维护者更容易看出在`Pull Request`中做了什么内容。

 ### 小红`push`功能到她的`Bitbucket`仓库中
--- a/git-workflows-and-tutorials/workflow-centralized.md
+++ b/git-workflows-and-tutorials/workflow-centralized.md
@@ -46,7 +46,7 @@
 在开发者提交自己功能修改到中央库前，需要先`fetch`在中央库的新增提交，`rebase`自己提交到中央库提交历史之上。
 这样做的意思是在说，『我要把自己的修改加到别人已经完成的修改上。』最终的结果是一个完美的线性历史，就像以前的`SVN`的工作流中一样。

-如果本地修改和上游提交有冲突，`Git`会暂停`rebase`过程，给你手动解决冲突的机会。`Git`解决合并冲突，用和生成提交一样的[`git status`](https://www.atlassian.com/git/tutorial/git-basics#!status)和[`git add`](https://www.atlassian.com/git/tutorial/git-basics#!add)命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，`Git`可以很简单中止整个`rebase`操作，重来一次（或者让别人来帮助解决）。
+如果本地修改和上游提交有冲突，`Git`会暂停`rebase`过程，给你手动解决冲突的机会。`Git`解决合并冲突，用和生成提交一样的[`git status`](https://www.atlassian.com/git/tutorials/inspecting-a-repository#git-status)和[`git add`](https://www.atlassian.com/git/tutorials/saving-changes#git-add)命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，`Git`可以很简单中止整个`rebase`操作，重来一次（或者让别人来帮助解决）。

 :beer: 示例
 ---------------------
@@ -73,7 +73,7 @@ git init --bare /path/to/repo.git

 ![](images/git-workflow-svn-clone.png)

-下一步，各个开发者创建整个项目的本地拷贝。通过[`git clone`](https://www.atlassian.com/git/tutorial/git-basics#!clone)命令完成：
+下一步，各个开发者创建整个项目的本地拷贝。通过[`git clone`](https://www.atlassian.com/git/tutorials/setting-up-a-repository#git-clone)命令完成：

 ```bash
 git clone ssh://user@host/path/to/repo.git
@@ -110,7 +110,7 @@ git commit # 提交文件

 ![](images/git-workflow-svn-3.png)

-一旦小明完成了他的功能开发，会发布他的本地提交到中央仓库中，这样其它团队成员可以看到他的修改。他可以用下面的[`git push`命令](https://www.atlassian.com/git/tutorial/remote-repositories#!push)：
+一旦小明完成了他的功能开发，会发布他的本地提交到中央仓库中，这样其它团队成员可以看到他的修改。他可以用下面的[`git push`命令](https://www.atlassian.com/git/tutorials/syncing#git-push)：

 ```bash
 git push
@@ -156,7 +156,7 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.

 ![](images/git-workflow-svn-5.png)

-小红用[`git pull`](https://www.atlassian.com/git/tutorial/remote-repositories#!pull)合并上游的修改到自己的仓库中。
+小红用[`git pull`](https://www.atlassian.com/git/tutorials/syncing#git-pull)合并上游的修改到自己的仓库中。
 这条命令类似`svn update`——拉取所有上游提交命令到小红的本地仓库，并尝试和她的本地修改合并：

 ```bash
@@ -190,7 +190,7 @@ CONFLICT (content): Merge conflict in <some-file>

 ![](images/git-workflow-svn-8.png)

-`Git`很赞的一点是，任何人可以解决他自己的冲突。在这个例子中，小红可以简单的运行[`git status`](https://www.atlassian.com/git/tutorial/git-basics#!status)命令来查看哪里有问题。
+`Git`很赞的一点是，任何人可以解决他自己的冲突。在这个例子中，小红可以简单的运行[`git status`](https://www.atlassian.com/git/tutorials/inspecting-a-repository#git-status)命令来查看哪里有问题。
 冲突文件列在`Unmerged paths`（未合并路径）一节中：

 ```
@@ -201,7 +201,7 @@ CONFLICT (content): Merge conflict in <some-file>
 # both modified: <some-file>
 ```

-接着小红编辑这些文件。修改完成后，用老套路暂存这些文件，并让[`git rebase`](https://www.atlassian.com/git/tutorial/rewriting-git-history#!rebase)完成剩下的事：
+接着小红编辑这些文件。修改完成后，用老套路暂存这些文件，并让[`git rebase`](https://www.atlassian.com/git/tutorials/rewriting-history#git-rebase)完成剩下的事：

 ```bash
 git add <some-file> 
@@ -210,7 +210,7 @@ git rebase --continue

 要做的就这些了。`Git`会继续一个一个地合并后面的提交，如其它的提交有冲突就重复这个过程。

-如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行[`git pull --rebase`](https://www.atlassian.com/git/tutorial/remote-repositories#!pull)命令前的样子：
+如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行[`git pull --rebase`](https://www.atlassian.com/git/tutorials/syncing#git-pull)命令前的样子：

 ```bash
 git rebase --abort
--- a/git-workflows-and-tutorials/workflow-feature-branch.md
+++ b/git-workflows-and-tutorials/workflow-feature-branch.md
@@ -62,7 +62,7 @@

 ![](images/git-workflow-feature-branch-2.png)

-在开始开发功能前，小红需要一个独立的分支。使用下面的命令[新建一个分支](https://www.atlassian.com/git/tutorial/git-branches#!checkout)：
+在开始开发功能前，小红需要一个独立的分支。使用下面的命令[新建一个分支](https://www.atlassian.com/git/tutorials/using-branches#git-checkout)：

 ```bash
 git checkout -b marys-feature
@@ -102,7 +102,7 @@ git push -u origin marys-feature

 ![](images/git-workflow-feature-branch-4.png)

-小红吃完午饭回来，完成整个功能的开发。[在合并到`master`之前](https://www.atlassian.com/git/tutorial/git-branches#!merge)，
+小红吃完午饭回来，完成整个功能的开发。[在合并到`master`之前](https://www.atlassian.com/git/tutorials/git-merge)，
 她发起一个`Pull Request`让团队的其它人知道功能已经完成。但首先，她要确认中央仓库中已经有她最近的提交：

 ```bash
--- a/git-workflows-and-tutorials/workflow-forking.md
+++ b/git-workflows-and-tutorials/workflow-forking.md
@@ -35,15 +35,15 @@

 这个仓库拷贝作为他个人公开仓库 ——
 其它开发者不允许`push`到这个仓库，但可以`pull`到修改（后面我们很快就会看这点很重要）。
-在创建了自己服务端拷贝之后，和之前的工作流一样，开发者执行[`git clone`命令](https://www.atlassian.com/git/tutorial/git-basics#!clone)克隆仓库到本地机器上，作为私有的开发环境。
+在创建了自己服务端拷贝之后，和之前的工作流一样，开发者执行[`git clone`命令](https://www.atlassian.com/git/tutorials/setting-up-a-repository#git-clone)克隆仓库到本地机器上，作为私有的开发环境。

 要提交本地修改时，`push`提交到自己公开仓库中 —— 而不是正式仓库中。
 然后，给正式仓库发起一个`pull request`，让项目维护者知道有更新已经准备好可以集成了。
 对于贡献的代码，`pull request`也可以很方便地作为一个讨论的地方。

 为了把功能集成到正式代码库，维护者`pull`贡献者的变更到自己的本地仓库中，检查变更以确保不会让项目出错，
-[合并变更到自己本地的`master`分支](https://www.atlassian.com/git/tutorial/git-branches#!merge)，
-然后[`push`](https://www.atlassian.com/git/tutorial/remote-repositories#!push)`master`分支到服务器的正式仓库中。
+[合并变更到自己本地的`master`分支](https://www.atlassian.com/git/tutorials/git-merge)，
+然后[`push`](https://www.atlassian.com/git/tutorials/syncing#git-push)`master`分支到服务器的正式仓库中。
 到此，贡献的提交成为了项目的一部分，其它的开发者应该执行`pull`操作与正式仓库同步自己本地仓库。

 ### 正式仓库
@@ -68,7 +68,7 @@
 和任何使用`Git`项目一样，第一步是创建在服务器上一个正式仓库，让所有团队成员都可以访问到。
 通常这个仓库也会作为项目维护者的公开仓库。

-[公开仓库应该是裸仓库](https://www.atlassian.com/git/tutorial/git-basics#!init)，不管是不是正式代码库。
+[公开仓库应该是裸仓库](https://www.atlassian.com/git/tutorials/setting-up-a-repository#git-init)，不管是不是正式代码库。
 所以项目维护者会运行像下面的命令来搭建正式仓库：

 ```bash
@@ -125,7 +125,7 @@ git remote add upstream https://user@bitbucket.org/maintainer/repo.git

 ![](images/git-workflows-forking-4.png)

-在刚克隆的本地仓库中，开发者可以像其它工作流一样的编辑代码、[提交修改](https://www.atlassian.com/git/tutorial/git-basics#!commit)和[新建分支](https://www.atlassian.com/git/tutorial/git-branches#!branch)：
+在刚克隆的本地仓库中，开发者可以像其它工作流一样的编辑代码、[提交修改](https://www.atlassian.com/git/tutorials/saving-changes#git-commit)和[新建分支](https://www.atlassian.com/git/tutorials/using-branches#git-branch)：

 ```bash
 git checkout -b some-feature
@@ -133,13 +133,13 @@ git checkout -b some-feature
 git commit -a -m "Add first draft of some feature"
 ```

-所有的修改都是私有的直到`push`到自己公开仓库中。如果正式项目已经往前走了，可以用[`git pull`命令](https://www.atlassian.com/git/tutorial/remote-repositories#!pull)获得新的提交：
+所有的修改都是私有的直到`push`到自己公开仓库中。如果正式项目已经往前走了，可以用[`git pull`命令](https://www.atlassian.com/git/tutorials/syncing#git-pull)获得新的提交：

 ```bash
 git pull upstream master
 ```

-由于开发者应该都在专门的功能分支上工作，`pull`操作结果会都是[快进合并](https://www.atlassian.com/git/tutorial/git-branches#!merge)。
+由于开发者应该都在专门的功能分支上工作，`pull`操作结果会都是[快进合并](https://www.atlassian.com/git/tutorials/git-merge)。

 ### 开发者发布自己的功能

@@ -169,7 +169,7 @@ git push origin feature-branch
 1. `pull`代码到他自己的本地仓库，再手动合并

 第一种做法更简单，维护者可以在`GUI`中查看变更的差异，做评注和执行合并。
-但如果出现了合并冲突，需要第二种做法来解决。这种情况下，维护者需要从开发者的服务端仓库中[`fetch`](https://www.atlassian.com/git/tutorial/remote-repositories#!fetch)功能分支，
+但如果出现了合并冲突，需要第二种做法来解决。这种情况下，维护者需要从开发者的服务端仓库中[`fetch`](https://www.atlassian.com/git/tutorials/syncing#git-fetch)功能分支，
 合并到他本地的`master`分支，解决冲突：

 ```bash
--- a/git-workflows-and-tutorials/workflow-gitflow.md
+++ b/git-workflows-and-tutorials/workflow-gitflow.md
@@ -41,8 +41,8 @@

 ### 功能分支

-每个新功能位于一个自己的分支，这样可以[`push`到中央仓库以备份和协作](https://www.atlassian.com/git/tutorial/remote-repositories#!push)。
-但功能分支不是从`master`分支上拉出新分支，而是使用`develop`分支作为父分支。当新功能完成时，[合并回`develop`分支](https://www.atlassian.com/git/tutorial/git-branches#!merge)。
+每个新功能位于一个自己的分支，这样可以[`push`到中央仓库以备份和协作](https://www.atlassian.com/git/tutorials/syncing#git-push)。
+但功能分支不是从`master`分支上拉出新分支，而是使用`develop`分支作为父分支。当新功能完成时，[合并回`develop`分支](https://www.atlassian.com/git/tutorials/git-merge)。
 新功能提交应该从不直接与`master`分支交互。

 ![](images/git-workflow-release-cycle-2feature.png)
@@ -89,14 +89,14 @@

 ![](images/git-workflow-release-cycle-5createdev.png)

-第一步为`master`分支配套一个`develop`分支。简单来做可以[本地创建一个空的`develop`分支](https://www.atlassian.com/git/tutorial/git-branches#!branch)，`push`到服务器上：
+第一步为`master`分支配套一个`develop`分支。简单来做可以[本地创建一个空的`develop`分支](https://www.atlassian.com/git/tutorials/using-branches#git-branch)，`push`到服务器上：

 ```bash
 git branch develop
 git push -u origin develop
 ```

-以后这个分支将会包含了项目的全部历史，而`master`分支将只包含了部分历史。其它开发者这时应该[克隆中央仓库](https://www.atlassian.com/git/tutorial/git-basics#!clone)，建好`develop`分支的跟踪分支：
+以后这个分支将会包含了项目的全部历史，而`master`分支将只包含了部分历史。其它开发者这时应该[克隆中央仓库](https://www.atlassian.com/git/tutorials/setting-up-a-repository#git-clone)，建好`develop`分支的跟踪分支：

 ```bash
 git clone ssh://user@host/path/to/repo.git
@@ -113,7 +113,7 @@ git checkout -b develop origin/develop

 ![](images/git-workflow-release-cycle-6maryjohnbeginnew.png)

-这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于`master`分支，而是应该[基于`develop`分支](https://www.atlassian.com/git/tutorial/git-branches#!checkout)：
+这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于`master`分支，而是应该[基于`develop`分支](https://www.atlassian.com/git/tutorials/using-branches#git-checkout)：

 ```bash
 git checkout -b some-feature develop
@@ -208,7 +208,7 @@ git merge issue-#001
 git push
 ```

-就像发布分支，维护分支中新加这些重要修改需要包含到`develop`分支中，所以小红要执行一个合并操作。然后就可以安全地[删除这个分支](https://www.atlassian.com/git/tutorial/git-branches#!branch)了：
+就像发布分支，维护分支中新加这些重要修改需要包含到`develop`分支中，所以小红要执行一个合并操作。然后就可以安全地[删除这个分支](https://www.atlassian.com/git/tutorials/using-branches#git-branch)了：

 ```bash
 git checkout develop