前言

上周末TB去了张家口滑雪，距离我上一次滑雪已经快三年了，大致是转行做iOS开发的三年，为什么会我在28岁的年纪会做一些不太容易的改变，也许从我在滑雪这项运动中学到的不无关系。这篇文章是我三年前最后一次滑完雪写的，时间是2014年2月19日，这次滑雪回来之后想起这篇文章，今天翻出来读了读，自我感觉良好，就收录起来。

原文

昨天我们一行四人去了北京较好的渔阳滑雪场滑雪一天，我的三位朋友都是初次滑雪，一上午下来，他们闷闷不乐，表示老摔跤却还没学会下初级道，下午和他们碰头回去的时候，各个脸上都挂着喜洋洋，我能想到他们会找到滑雪的乐趣，不过还是被这前后反差给吃惊。能让他们玩的开心，也算我不虚此行。

朋友和我去滑雪，我想是他们因为喜欢雪的缘故，才把初次交给我的吧。我以前以为只有我特别喜欢雪，我的确是因为北方有大雪才来这，也因此更享受在北京的日子，这几年雪季也去到北方的一些城市逛了逛，但是后来我才明白几乎每个人都喜欢雪，目前我还没听说有谁不喜欢，每年下雪的时候兴奋的不只是我而是所有人，后来看了一本书《新世界》，我才明白，原来我们喜欢雪，花，阳光等是因为他们代表生命的源头和本质。而滑雪的时候更能感受到雪的美，你站在雪场或者和缆车一起飘在空中，都可以看着一条条洁白宽敞的雪道，心中自发涌出一种愉悦的心情。

我第一次滑雪是在12年元旦去黑龙江旅行的时候，是和驴友在雪乡附近一个农民自建的简陋的滑雪场玩了不到一个小时。和我的朋友们一样也摔了很多跤，但是摔完之后并没有想象的疼，所以依然敢于一次一次地站上雪道坡顶，继续挑战。人性本来就是喜欢挑战自我，不断想要改变的，当有一项自我挑战的运动在你面前，挑战失败的后果并不像自己以为以及别人以为的那样严重，当然会觉得很有乐趣，因此我喜欢上了这项运动，回来之后连续去了多次。对滑雪摔跤的这种感受也适用于我的生活，因为生活中，每个人也会经历许多坎坷，但是经历过后，我们还依然好好的活着，并不会像想像的失去那么多。

12年的雪季我学会了“内八字”减速下滑后上了初级道然后又挑战了中级道。去年我主要在中级道学习一些技巧，比如“蛇型”，“犁式”滑雪，去年也是我滑雪最多的一年，本有很多机会去尝试高级道的，但一直不太有勇气上去。今年的雪季因为工作以及被其他事情占据，一直没有时间去滑雪，昨天去滑雪不仅没有学会什么技巧，而且明显生疏不少，在经过上午和下午熟悉初级道、中级道以及较难中级道后，我鼓足了勇气想要在最后一个小时挑战一下高级道，在上高级道的缆车上心里很忐忑，怕上去之后太陡不敢下来，又怕摔出雪道很危险，也怕在一些高手面前出丑（看看人就是这样，都被过去深深的伤过）。还好我战胜了这些杂念，上了两次高级道，一次安全滑下，一次中途摔了两次，加起来四肢自由滑行了至少30米，衣服也进了很多雪水很不舒服，手掌摩擦的发烫（现在感觉依然很光滑），但我也和我的朋友一样也很享受进步的开心，我开心不只是因为挑战高级道成功，而是因为挑战自己成功。我这三年多在雪道上的成长也大体也是我在北京四年多的缩影吧，越来越高越来越好。

滑雪极大的乐趣就是滑行了，人类本性就喜欢不断追求速度，原本只会行走，后来利用车，飞机等工具让速度不断提升，滑雪是人类借助最简单的工具来提高自己的速度的工具之一，而且可以自由掌控速度和滑行弧度。在下滑的过程中行走的曲线，雪板和雪摩擦的声音和溅起来的雪花，这些美的观感，让我以及其他滑雪爱好者愿意乐此不疲的在同一雪道不停的往返。

滑雪还有的乐趣就是静下来享受当下，缓慢的缆车以接近蜗牛的速度一样升起前行，而在缆车上你能做的事情不多，只能看看远方的山水，雪道上各种水平滑雪者的滑姿；呼吸郊外雪山上清新的空气；听寒风划过山间。

由于工作的原因，我现在依然坚持的运动主要就篮球，网球和滑雪了。我是各种体育运动的爱好者，也清楚他们的不同。虽然他们都需要不断的突破自己，篮球和网球因为有对手所以更多的是在挑战别人，从赢球上找到乐趣，而滑雪几乎是挑战自我的运动，从突破自我中找到乐趣。在球场上有时候会有争吵和摩擦，因为会有些猛男以战胜别人为快乐而输了则大为光火，因此也需要我懂得球场上和各种猛男相处，因此并不只是享受运动本身。而滑雪不同，你更多的时候是在跟此刻的内心去博弈，因此更能享受运动本身的乐趣。我看过几本灵性成长的书籍，明白向外寻求的快乐会很容易带来相应的沮丧，因为外面的不会永远属于你，而向自己内心去寻求的快乐则相对可靠的多。

我的各种运动爱好和生活一样能带给我很多感悟，滑雪也不例外。滑雪带给我和其他体育爱好不同的启发，它让我更享受自我成长，回归到生命的本质。

玩转git分支

这是一篇介绍git分支的综合性教程。首先，我们会简单介绍分支的创建，它就像请求一个新项目的历史一样。然后，我们将看看如何使用git checkout选择分支。最后，我们将学习使用git merge进行各个独立的分支合并。在你阅读的时候，记住git的分支和svn的分支不同，svn的分支仅仅用来捕获偶尔大范围的开发，然后git分支却是你每日工作流必不可少的部分。

git分支

一个分支代表一个独立的开发流水线，在本教程的第一部分的git基础（Git Basics）章节中我们介绍了编辑／暂存／提交过程，分支就是这些流程的抽象。你可以把分支看作请求一个新的工作目录区、暂存区、项目提交历史的方法。新的提交会在当前分支的提交历史中记录，在项目历史中导致一个分流（fork）。

git branch命令让你创建、列出、重命名和删除分支。它不会让你在不同分支中切换，也不会让你的分流开发的历史再次合并回一起。因此git branch和git checkout 和 git merge 命令紧密联系在一起工作。

如何使用

git branch

列出仓库的分支历史

git branch <branch>

创建一个叫做<branch>的新的分支，这个命令不会切换到这个新分支。

git branch -d <branch>

删除指定分支。在git中这是一个安全的操作，因为如果该分支存在没有合并的修改git会阻止你删除分支。

git branch -D <branch>

强制删除一个指定分支，不管有没有未合并的修改，当你想永久删除这个开发流水线上所有提交历史时可以使用这个命令。

git branch -m <branch>

重命名当前分支名为<branch>。

讨论

在git中，分支是你日常开发过程的一部分。当你想添加一个新的功能或者想修复一个bug，无论他们的大或者小，你都可以创建一个分支将他们封装起来。这可以确保不稳定的代码不会提交到主要核心代码里。并且在你合并到主分支之前让你有机会清理功能开发的历史。

举个例子，上图形象地展示了一个包含两个独立开发的流水线的仓库，一个开发小功能，另外一个开发一个耗时较大的功能。通过将他们包含在不同分支中开发，不仅仅可以让开发工作可以并行，而且保证主分支master不会被有问题的代码污染。

分支节点（Branch Tips）

git分支实现比svn要轻量级的多。git不需要拷贝目录的文件到另一个目录，git存储一个分支作为一个提交的索引。这样看来，分支代表着一系列提交的节点（tip），而不是多个提交的容器。通过提交之间的关系来推断一个分支的历史。在git合并模型中这有巨大的影响。svn中的合并是基于文件的，而在git中让使用提交进行工作，这个更加抽象。事实上在项目提交历史中你可以把合并看作是两个独立的提交历史的连接。

举个例子

创建分支

理解分支仅仅是指向提交的指针这个概念非常重要。当你创建分支，git所需要作的仅仅是一个指针——它不会对仓库造成任何修改，因此，如果你像下面这样开始在一个仓库上开发。

然后，你使用如下命令创建一个分支：

git branch crazy-experiment

仓库的历史依然不会修改，你只是拥有了一个指向当前提交的指针：

主要这仅仅是创建了一个新的分支。为了添加一个提交，你需要使用git checkout选择一个分支，然后使用标准的git add 和 git commit命令。请查看这篇文章的git checkout 段落了解更多。

删除分支

当你在一个分支上完成开发，并且把该分支的修改合并进了主要代码库，现在你不用担心丢失任何修改提交历史就可以删除分支了。

git branch -d crazy-experiment

然而，如果你的分支没有合并，上面这个命令会产生如下错误信息：

error: The branch 'crazy-experiment' is not fully merged.
If you are sure you want to delete it, run 'git branch -D crazy-experiment'.

这可以防止你丢失对这些提交的索引，这意味着你失去了对这条分支开发流水线的访问。如果你真的想要删除这个分支（比如，这个分支开发完全是一次失败的实验），你可以使用大些的-D标志：

git branch -D crazy-experiment

这将删除这个分支，不管这个分支是什么状态，它不会给出任何警告，所以使用这个命令要特别小心。

git checkout

git checkout命令可以让你在创建的分支上自由切换，切换一个分支会更新工作目录的文件，保持和该分支的版本控制的内容一致。它会让git记录在当前分支上的所有新的提交。把切换分支想象成你去选择一个你想从事开发工作的开发流水线。

在前面的章节，我们知道了如何使用git checkout查看过去的提交。切换分支和被更新到选择的分支和修改的工作目录类似，不过，新的修改会被保存到项目版本历史——意味着，这不是一个只读操作。

如何使用

git checkout <existing-branch>

切换到指定分支，这个分支应当是之前已经使用git branch创建过的分支，这个命令让已经存在的分支称为当前分支，并且对应会更新当前工作目录。

git checkout -b <new-branch>

创建并切换到<new-branch>分支，-b选项会让git先执行git branch <new-branch>再执行git checkout <new-branch>操作。

git checkout -b <new-branch> <existing-branch>

和之前的命令类似，但是不是基于当前分支创建新分支，而是基于<existing-branch>这个分支创建和切换新分支。

讨论

git checkout和git branch并肩而战，当我们想开始一个新功能开发时，我们先使用git branch创建分支，然后使用git checkout切换分支。你可以使用git checkout命令在一个仓库的多个功能分支上切换。

为每个功能使用一个专门分支，这是相比svn的工作流来说一个巨大的变化。它让尝试一个新实验变的极其容易，因为你完全不需要担心损坏已经存在的功能，并且让多个不相关的功能同时开发变的可能。而且，分支也让多种合作开发流工作的更顺手。

分离头（Detached HEADs）

刚才我们介绍了 git checkout的三种使用方法。现在我们来聊聊我们上一章节提到过的分离头（Detached HEADs），记住头（HEAD）在git中是我们用来索引当前快照的方式。在git内部实现中，git checkout命令指示简单的更新指向指定分支或者提交的头（HEAD）。当指向一个分支时，Git不会有任何提示，但是当你切换提交时，git就进入了分离头（Detached HEAD）状态。

这个警告告诉你将作的所有事情已经和项目开发的其他部分分离（detached）了。如果你要在一个分离头状态下开发一个新功能，你将没有分支可以允许你回到该开发。当你切换到另外一个分支（比如，进行合并你的开发），你将没有你的功能开发的索引：

特别指出，因此你的开发应当永远在分支上进行——不要在分离头上进行。这将确保你能索引到你最新的提交。然而，如果你只是想看看以前的提交的内容，是否进入分离头模式就无所谓了。

举个例子

下面歌命令展示了基本的git 分支处理过程。当你想要做一个新功能开发时，你创建一个专门的分支，切换到该分支：

git branch new-feature
git checkout new-feature

然后，我们就像之前章节讲到的一样提交新的快照。

# Edit some files
git add <file>
git commit -m "Started work on a new feature"
# Repeat

所有这些将被记录在新的功能分支new-feature上，完全和master分支分隔开来。你想提交多少次就提交多少次，完全不需要担心其他分支发生了什么。当到了需要切换到正式代码库时，只需要简单的切换到master分支即可：

git checkout master

这个会告诉你仓库的状态，然后你可以选择是否合并已经完成的功能，或者创建一个新的分支开始一个另一个不相关的功能，或者在项目的稳定代码master分支上工作。

git merge

合并可以让一个分叉的分支历史合再次合并到一起。git merge命令让你将git branch 创建的独立开发流水线集成合并进一个单一的分支。

注意下面所有的命令会合并进当前分支，当前分支会拥有合并后的结果，目标分支则完全不受影响。再此强调，git merge总是和用于选择当前分支的git checkout 命令结合起来使用，然后使用git branch -d命令用来删除无用的目标分支。

如何使用

git merge <branch>

Merge the specified branch into the current branch. Git will determine the merge algorithm automatically (discussed below).

合并指定分支到当前分支，git会自动采取合并的算法（后面再讨论这个）。

git merge --no-ff <branch>

合并指定分支到当前分支，但是总是会产生一个合并提交（甚至是线性向前（fast-forward）合并）。这个对于想归档仓库所有的发生的合并有用。

讨论

单你在一个独立的分支上完成一个功能，你肯定希望合并进主要代码库，git会根据你的仓库的接口，可以采取线性向前方式或者3-way方式完成合并。

当当前分支节点到目标分支有一个线性路径时会使用线性向前合并（fast-forward merge），这样它不用发生真正的合并，git仅仅会通过移动当前分支节点到目标分支节点来集成合并历史。合并非常高效，因为目标分支的所有的提交现在可以在当前分支查得到。举例来说，一个线性向前的合并some-feature到master像下图所示：

However, a fast-forward merge is not possible if the branches have diverged. When there is not a linear path to the target branch, Git has no choice but to combine them via a 3-way merge. 3-way merges use a dedicated commit to tie together the two histories. The nomenclature comes from the fact that Git uses three commits to generate the merge commit: the two branch tips and their common ancestor.
但是，当分支之间都有分叉时线性向前和冰就不可能了。当没有线性路径到目标分支时，git别无选择只能采取3-way合并。3-way合并使用一个专门的提交来将两个分支历史捆绑在一起。这个明明源自git使用了三个提交来生成合并提交：两个分支节点和他们共同的祖先提交。

你可以使用这些合并策略，然后很多开发者喜欢为小功能开发或者bug修复使用线性向前合并（通过使用rebasing命令可以很容易实现），同时在较大较长耗时的功能开发时使用3-way合并，在前面的例子中，产生的合并提交用来作为合并两个分支的象征性连接点。

解决冲突

如果你尝试合并两个分支时，者两个分支对同一个文件的同一部分作了修改，git这时候不清楚你要运用哪个版本的修改。当这种情况发生时，它会停止合并提交，以便让你去手动解决冲突。

git牛逼的地方就是合并过程中解决合并冲突就类似之前提到的编辑／暂存／提交的工作流程。当你遇到合并冲突时，执行git status 命令，它会告诉你哪个文件冲突需要解决，例如，如果两个分支都修改了hello.py文件的同一部分，你将看到类似如下内容：

# On branch master
# Unmerged paths:
# (use "git add/rm ..." as appropriate to mark resolution)## both modified: hello.py#

然后，你就可以找到这个文件根据你的需要修复这个合并冲突，当你准备完成合并时，你只需要执行在冲突的文件上git add命令，告诉git冲突已经解决，然后，你可以执行git commit命令来生成一个合并提交。这和生成一个普通快照完全相同，因此对一般开发者来说管理他们的合并非常容易。

记住，合并冲突只会发生在3-way合并中，不太可能在线性向前合并中发生有冲突的修改。

举例说明

线性向前合并

我们的第一个例子展示一个线性向前合并。下面的代码先创建一个新的分支，添加了两个提交，然后将这个分支合并集成到主干线上，这是一个线性向前合并过程。

# Start a new feature
git checkout -b new-feature master
# Edit some files
git add <file>
git commit -m "Start a feature"# Edit some files
git add <file>
git commit -m "Finish a feature"
# Merge in the new-feature branch
git checkout master
git merge new-feature
git branch -d new-feature

在短小分支上经常使用这个工作流，比大功能开发用的多。

注意这个时候可以使用git branch -d删除该新分支，因为新功能开发 的提交已经可以在master分支上访问得到了。

3-Way合并

下一个例子非常类似，但是在master已经有修改进展，功能开发也有修改进展，所以这个时候git会使用3-Way合并，这个在大型功能开发时很常见，在多个开发者同时在项目上开发时也很常见。

# Start a new feature
git checkout -b new-feature master
# Edit some files
git add <file>
git commit -m "Start a feature"
# Edit some files
git add <file>
git commit -m "Finish a feature"
# Develop the master branch
git checkout master
# Edit some files
git add <file>
git commit -m "Make some super-stable changes to master"
# Merge in the new-feature branch
git merge new-feature
git branch -d new-feature

注意对于这个例子git不可能执行线性向前合并，因为如果不原路返回（backtracking）master没法直接移动到新功能上去。在实际工作中，new feature很可能是一个大型耗时的项目开发，在开发它的过程中很可能已经有别的修改加到master上去了，但是如果是一个小的功能开发，你可以在master上使用rebase命令来执行线性向前合并，这样可以减少多余的合并提交，从而防止项目版本历史变得混乱。

原文出处

Using Branches

Git同步（Syncing）

在SVN中开发者使用一个中央仓库来合作开发。大家通过将代码在工作区和中央仓库之间传输来合作开发。这跟git的合作模式完全不同，git中开发者拥有仓库的完整拷贝，提交历史、分支结构都是完整的。用户通常提交一系列本地提交而不是单一的修改到服务器。git可以让你在不同仓库间分享所有分支。
下面的命令用来管理所有仓库连接。通过push分支到中央仓库来提交修改，通过pull远程仓库到本地仓库来查看其他人的修改。

git remote

git remote 命令让你可以创建、查看和删除同其他仓库的连接。远程连接类似浏览器中的标签（bookmark）而不是直接链接其他仓库。git为了方便大家使用别名代替URL
。例如，下面的表格向你展示连接至中央仓库和其他开发者仓库的两个连接，他们在git命令中传入origin和john而不是完整的URL。

如何使用

git remote

列出你本地所有其他仓库的连接

git remote -v

和之前的命令类似，不过这个命令执行结果包含每个连接的URL。

git remote add <name> <url>

创建一个远程仓库的连接。在添加完连接后，你可以在其他命令中使用代替URL。

git remote rm <name>

删除一个叫的远程连接。

git remote rename <old-name> <new-name>

重命名一个远程连接。使用新名字代替旧名。

讨论

Git的设计让开发者拥有完全独立的开发环境。这意味着信息不会自动在仓库之间传输。而需要开发者手动拉取上游的提交到本地仓库，或者推送回本地提交到中央仓库。git remote命令是传递URL给分享（sharing）命令的更容易的方式。

The origin Remote

当你使用clone命令clone一个仓库时，它自动回创建一个叫做origin指向被克隆的远程仓库。这个对开发者在创建一个远程仓库拷贝非常有用，因为它为开发者提供了很容易的方式来拉取上游改变或者发布本地提交。这也是为什么大多数采取git管理源代码的远程仓库被称作origin。

Repository URLs

Git支持许多连接远程仓库的方式。两个最简单的连接远程仓库的方式是通过http和ssh协议。http可以很容易的允许匿名访问，只读访问一个仓库，比如：

http://host/path/to/repo.git

但是，它通常不太容易推送提交到http地址（通常我们不希望允许匿名推送）。为了拥有读写访问，你应当使用ssh协议替代：

ssh://user@host/path/to/repo.git

你将需要在主机上有一个有效的ssh账号，git支持通过ssh授权访问。

示例

在origin之外，也很容易添加你队友的仓库连接。比如，如果你的同事小明，维护一个对外发布的可访问仓库dev.example.com/john.git，你可以通过下面这条命令添加一个连接：

git remote add john http://dev.example.com/john.git

可以添加某个开发者的仓库，让git可以在中央仓库之外进行合作。这对小团队在大型项目中合作非常有用。

git fetch

git fetch命令会从远程仓库倒入提交到本地仓库。最终提交结果存储在远程分支而不是一般的本地工作分支。这让你有机会在将修改集成到你的项目拷贝前评审（review）代码。

使用

git fetch <remote>

获取远程仓库所有分支。这个命令同时会下载这个仓库的所有需要下载的提交和文件。

git fetch <remote> <branch>

可前面的命令类似，但是它只获取指定的分支。

讨论

获取(fetching)可以让你知道其他同事写了哪些代码。因为获取的内容存储在一个远程分支上。它不会影响你本地开发工作。获取可以让你将代码集成到本地仓库之前安全地评审（review）修改。这个和svn update类似，可以让你知道中央仓库的提交历史的进度，但是它并不强制合并这些修改到你的仓库。

Remote Branches

远程仓库就像本地仓库一样，除了他们代表其他人仓库的提交。你可以像本地仓库一样 检出（checkout）一个远程仓库。但是这让你进入分离头（detached HEAD）状态（类似检出到一个以前的提交一样）。你可以把远程分支看成不可修改的分支。你可以在git branch命令中加上-r参数来查看原称分支。查看到的远程分支会在前面加上他们所属的远程仓库，这样你就不会将他们和本地分支混淆。例如，下面的命令块展示了在执行fetch命令后所有origin下的分支。

git branch -r
#origin/master
#origin/develop
#origin/some-feature

再说一次，你可以使用git checkout 和git log命令来查看分支内容。如果你觉得远程分支的修改没有问题，你可以使用git merge命令把他们合并进本地分支了。因此和SVN不同，git同步你的本地仓库和远程仓库需要两步过程：获取和合并。git pull命令是这两步骤的结合，让这两步变成一步。

举例

这个例子展示一个典型的工作流中是如何同步你的本地仓库和你中央仓库的master分支。

git fetch origin

这个命令会展示下载的分支。

a1e8fb5..45e66a4 master -> origin/master
a1e8fb5..9e8ab1c develop -> origin/develop
* [new branch] some-feature -> origin/some-feature

下方表格中的方框代表远程分支的提交，如图所示，git fetch让你拥有访问其他仓库整个分支结构的权限。

为了查看上游的master分支增加哪些提交，你可以使用git log ，并使用origin/master作为条件。

git log --oneline master..origin/master

为了通过修改并合并他们到你本地的master，你可以使用如下命令：

git checkout master
git log origin/master

然后我们能够使用git merge origin/master

git merge origin/master

这样origin/master分支和master分支就指向了同意个提交，并完成了和上游开发的同步了。

git pull

本地仓库和上游修改合并是git合作开发流的常见任务。我们已经知道了如何使用git fetch 加上 git merge来完成这项工作。但是git pull 一条命令就可以搞定。

使用

git pull <remote>

获取指定远程仓库的当前分支同名的拷贝，并立即和当前分支合并。这和git fetch <remote> 加上git merge origin/<current-branch>作用等同。

git pull --rebase <remote>

和上面的命令类似。但是它使用git rebase代替git merge来集成合并远程分支。

讨论

你可以把git pull看作git版的svn update，它让同步本地仓库和上游修改变的很容易。下图的表格展示了合并每一步的进行过程。

刚开始你的仓库是同步的，但是在你git fetch之后origin指向的仓库跟你上一次检查已经有了新的内容。然后你使用git merge立即将远程master集成合并到本地master。

Pulling 和 Rebase对比

--rebase能够确保线性分支历史，没有不必要的合并提交。许多开发者喜欢rebasing代替merging。因为它就好比告诉你：“我想让我的修改保持在其他人修改的上方”。从这个角度讲，使用 git pull 加上--rebase标志相比简单的git pull更像svn update

事实上，使用--rebase进行拉取非常普遍，以至于有一个它的专门的配置项：

git config --global branch.autosetuprebase always

执行这个命令之后，所有的git pull命令将会使用git rebase命令代替git merge。

举例

下面这个命令展示如何和中央仓库的master分支进行同步：

git checkout master
git pull --rebase origin

这个命令会将你本地的修改追加到其他同事修改的上面。

git push

推送（push）用于把本地仓库提交传输到远程仓库。它和git fetch作用相反。但是鉴于获取导入远程提交到本地分支，推送输出提交到远程分支，它有可能会覆盖修改，因此你需要小心的使用它。下面我们来讨论这些问题。

使用

git push <remote> <branch>

推送必要的的提交和内部对象到远程指定分支。这个将在目标仓库创建一个本地分支。为了阻止重写提交，当你推送会导致远程仓库出现non-fast-forward合并，git会阻止这样的推送。

git push <remote> --force

和上面的命令类似，但是不管是否会导致non-fast-forward合并它会强制推送。不要使用–force标志，除非你绝对清楚你这样做没有问题。

git push <remote> --all

推送所有的本地分支到指定远程仓库。

git push <remote> --tags

当你推送分支时标签（tags）不会自动推送，除非你使用了–tags选项。–tags将会发送所有的本地标签到远程。

讨论

git push通常用来将本地修改发布到远程中央仓库。当你在本地积累了几个提交之后并打算把他们发布出去，以便其他团队成员可以使用。你可以使用可交互的rebase精简提交，然后再推送到远程分支。

上图展示了你本地和远程master的差异。然后你通过git push origin master命令推送修改。注意git push的本质是在远程仓库内部执行了git merge master。

强制推送(Force Pushing)

当使用git push会导致non-fast-forword合并时，git为了防止复写中央仓库提交，会拒绝推送。因此，如果远程提交历史和你的本地提交历史不同，你需要拉取远程分支，合并到到本地分支，然后才能再次尝试推送。这跟SVN类似，你需要通过svn update和中央仓库同步，然后才能提交修改。

使用--force参数可以代替上面的步骤，让远程分支和本地分支匹配。在你上次推送之后，删除任何上游分支的修改有可能发生。只有当你知道你的提交有问题，然后你在本地用一个git commit --amend命令做了修改或者一个可交互的rebase之后，你可以使用强制推送（force push）。你必须确定在你使用--force选项之前没有其他同事拉取那些你提交的有问题的提交。

只推送到裸仓库

额外补充，你应当仅仅推送到使用--bare标志创建的仓库。因为推送会搞乱远程分支的结构。不用推送到另外一个开发者的仓库这一点很重要。但是裸仓库不包含任何工作目录，所以不太可能打断其他人的开发。

举例

下面的例子描述一个标准的发布本地代码到中央仓库的方法。首先，通过拉取中央仓库拷贝确保你本地分支最新，然后通过reabse合并你的修改到分支提交历史最上面。使用交互式合并（interactive rebase)也是在对外公开你的代码前清理提交的一个好机会。然后，git push命令将你所有本地仓库的提交发送到远程仓库。

git checkout master
git fetch origin master
git rebase -i origin/master
# Squash commits, fix up commit messages etc.
git push origin master

因为你已经确保了本地master分支是最新的，所以结果是fast-forward合并，git push不会报出任何我们之前讨论的non-fast-forward问题。

英文原文出处

《Syncing》

我打算翻译《Become a git guru》系列git教程文章，欢迎有兴趣翻译这系列教程的朋友加入我一起完成翻译。

译者注：这篇文章很好的介绍了如何使用合并申请功能来保证项目质量可靠性和帮助团队成员交流成长。文章使用了Bitbucket（一个类似github的代码共享网站）作为远程代码管理工具，国内开发者使用github居多，公司内部可能使用gitlab更多，不过译者认为他们使用方式大同小异，原理更是相通，所以还是决定原文翻译。如果有时间我会针对gitlab单独写一份教程。

使用Bitbucket的合并申请功能让开发者之间合作变的非常的easy。你可以使用Bitbucket提供的非常nice的网页管理界面让大家探讨这些修改，然后再合并代码到正式项目。

你可以仅仅使用合并申请功能来通知团队成员你已经完成了可一个功能开发。当开发者完成他们开发的功能后，他（她）可以登陆Bitbucket，然后发起合并申请。这可以让被通知到人去review代码并合并这些代码到master分支（译者注：应该是指团队主开发分支）。不过合并申请功能可不止发送通知这么简单——它可以用来作为讨论提出申请的功能的专用论坛。如果代码有任何问题，团队成员们可以提出反馈，甚至推送（push）提交来小小的修改代码。合并申请功能可以追踪这些事情。

跟其他团队合作模型相比，这个分享代码提交的方案使得开发流程更加顺畅。SVN和Git都可以通过简单脚本配置就可以自动发送邮件。然而当需要讨论修改时，如果依赖邮件，那将邮件满天飞，会让事情变的混乱，再加后续的修改提交，就更加恐怖了。合并申请把所有这些事情集合在一个web界面上。你仅仅需要请求另外一个开发者（比如，项目维护者）来从你的仓库拉取代码合并进他的仓库就可以完成一个合并申请。这意味着你发起合并申请需要提供4个信息：源仓库、源分支、目标仓库、目标分支。

Bitbucket为这四个值提供了合理的默认值。然而，根据不同项目不同合作开发流，你的团队可能需要设置不同的默认值。上面的图表展示如何请求从一个功能分支合并到正式的主干分支（master）。但合并申请的功能比这要多的多。

如何进行

合并申请可以被运用在功能分支工作流（Feature Branch Workflow）,
(GitFlow工作流(Gitflow Workflow),Forking工作流(forking WorkFlow)。但是合并申请需要在两个不同分支或者不同仓库之间进行，所以它不适用于标准意义上的集中式工作流（Centralized Workflow）。在不同开发工作流上使用合并申请略有不同，不过基本流程是一样的：

1. 开发者在本地仓库创建一个功能开发专用的分支。
2. 开发者将分支推送到远程仓库
3. 开发者发起合并申请
4. 团队成员review代码，展开讨论或者修改他们。
5. 项目维护者合并该分支到正式仓库然后关闭合并申请。

后面的内容我们来聊聊合并申请是如何助力不同的合作开发工作流的。

功能分支工作流中的合并申请

功能分支工作流主要用于在同一项目中管理团队合作开发的，开发者们为每个开发的的功能创建分支。但是在代码合并进主干分支前，开发者需要发起合并申请，让大家讨论他开发的功能，这些完成之后才能合并到正式代码里。

由于在功能分支工作流中只有一个公有仓库，因此合并申请的源仓库和目标仓库是一样的，一般来说开发者指定他的功能分支作为源分支，主干分支作为目标分支。

项目管理者在收到合并申请后，会去查看提交的代码，如果没有问题就会合并代码到主干分支并关闭申请，但是如果在修改的代码中发现问题，他可以在合并申请界面进行反馈，对应的修改提交会显示在评论的右边。

发起一个没有开发完成的功能也是允许的。比如当一个开发者在开发某个需求时遇到困难，他们可以发起包含需要提交的代码然后发起申请，其他开发者可以在合并申请界面提供建议，或者直接动手帮忙解决问题并提交修改。

GitFlow工作流中的合并申请

Gitflow工作流类似工作分支工作流，但是在项目发布周期中严格精确地定义了一个分支模型，在GitFlow工作流中加入合并申请可以让开发者围绕他们正在工作的发布分支或者维护分支进行讨论。

Gitflow工作流中合并申请的使用跟之前一样：一个开发者发起一个需要被review的功能、发布、热修复代码的合并申请，团队其他成员通过Bitbucket收到通知。功能开发通常合并进develop分支，然后发布分支和热修复分支通畅合并进develop和master两个分支。合并申请可以在所有这些合并中用到。

Forking工作流中的合并申请

在Forking工作流中，开发者将代码先推送到自己的仓库而不是公有仓库。然后，他可以发起合并申请请求项目管理者review代码。合并申请的通知功能在这个时候就特别有用，因为这可能是当开发者向项目管理者的仓库提交代码时项目管理者知道有新代码提交的唯一方式。

由于开发者有自己的公有仓库，当他们提起合并申请时候源仓库是和目标仓库不同，目标仓库是正式仓库，目标分支主干分支。

合并申请也可以运用于正式项目之外，例如，当你和队友合作开发一个功能时，这个时候我们发起合并申请可以使用对方仓库作为我们的目标仓库而不是正式项目，我们可以约定同一个功能名称作为源分支和目标分支。

你们可以在合并申请界面讨论和开发功能，当你们开发完后，你们中可以由一个人向正式项目发起合并申请。合并申请的这种灵活性在forking工作流中尤其有用。

举个例子

下面的例子说明了如何在forking工作流中使用合并申请。对小团队以为开源项目贡献代码的个人开发者一样有效。

在这个例子中，小红（Mary）是一个开发者，小明（John）是项目管理者。他们都有自己的公有仓库，并且小明拥有正式仓库。

小红拷贝（fork）正式仓库

为了给小明的项目贡献代码，小红需要先拷贝小明的仓库到自己的公有仓库，她可以登录bitbucket，找到小明的仓库然后点击fork按钮即可。

不一小会儿她就拥有了这个项目的一份拷贝了，注意看看姓名和描述是否改变。

小红克隆（clone）她的公有仓库

然后，小红需要克隆她刚才拷贝（fork）的仓库。这样子她在自己的设备上就有了可以开发的仓库了。我们通过命令实现：

git clone https://user@bitbucket.org/user/repo.git

时刻记住git clone会自动创建一个origin用来指向自己远程拷贝的分支。

小红开发一个新功能

在小红开发新功能时，小红需要创建一个分支用于开发功能。这个分支将是她发起合并申请时的源分支。

git checkout -b some-feature      
#Edit some codegit 
commit -a -m "Add first draft of some feature"

开发一个功能小红可能会有很多个提交（commit）。如果分支历史非常混乱她可以使用交互式合并(interactive rebase)来去除或者压缩（squash）无用的提交。在大型项目中，清理分支历史让项目的维护者更容易在合并申请里知道你的修改里做了什么事情。

小红将她开发的功能推送（push）到她的公有仓库

在她开发完功能后，小红将功能分支推送到她的远程仓库（不是别人维护的正式仓库，是她fork的仓库），她可以使用这个命令：

git push origin some-branch

这个让她的修改就在公有仓库里，这样其项目维护者或者其他开发者可以获取到她的修改。

小红创建合并申请

在代码push完成后，小红登录Bitbucket，找到她fork的项目，然后点击右上角的Pull request按钮发起合并申请。弹出表达默认设置小红的仓库为源仓库，病要求她设置源分支、目标仓库和目标分枝。

小红需要合并她的代码到正式项目，所以她设置她的分支为源分支，目标仓库为小明的共有正式仓库，目标分枝为主干分支master。她还需要输入标题和描述她的修改，然后在Reviewers 输入框选择能够同意她的修改的人（包括小明）。

在她创建合并申请后，小明就会通过邮件或者订阅收到通知。

小明评审（review）代码

小明可以在他的仓库通过点击标签 Pull request 来查看所有人的合并申请。点击小红的申请，他将看到小红的申请描述，她分支的提交历史，以及该分支代码包含的修改的差异对比（diff）。

如果他认为功能可以合并进正式项目，他只需要点击Merge按钮同意合并申请，然后就会合并小红的功能代码到他的主干分支master。

但是，假如小明在小红的代码里发现了小bug，需要小红在合并前修改代码，他可以在合并申请恢复，可以在大输入框里做一个整体评论，也可以选择一个具体的提交来评论。

小红添加随后的补充提交

如果小红对收到的反馈有任何问题，她可以在合并申请里恢复，类似论坛一样。为了修复错误，小红添加一个新的提交到她的分支，再推送到她的仓库，就像她之前做的那样。她的合并申请自然加到了原来的合并申请里了。然后小明就可以在他评论的地方再次评审。

小明同意合并

最后，小明同意这些修改，合并功能到master主干分支，关闭合并申请。这样功能代码就正式集成到项目了。所有这个项目的贡献者就可以使用标准的git pull拉取这些修改到他们本地的仓库了。

总结

现在你已经掌握了所有技能和工具来帮助你使用合并申请。记住，合并申请不是其他所有基于Git的工作流(Git-based collaboration workflows)的替代者，而是你和其他团队成员合作开发的有利补充。

英文原文出处

Making a Pull Request

前言

我之前做开发一直使用SVN,从上一家单位开始使用Git，到现在大概一年多时间。使用Git让我开发工作变的更自由更快,以及Git帮助团队代码管理和review更规范，现在我已经完全放弃使用SVN全身心拥抱Git。今天整理了一些SVN和Git的对比，希望阅读到此文使用SVN的开发团队能开始迁移到Git,引用习大大最近的一句话啊：世界潮流,浩浩荡荡，顺之则昌，逆之则亡。

Git对比SVN的优势

1.Git分支功能最为强大，分支管理能力让SVN望尘莫及

•    git：有本地分支
•    svn：无本地分支

git可以方便创建本地分支，且创建分支的时间是0(1)，即瞬间就创建好了。由于分支可以是本地的，也就不存在svn目录权限的问题。本地实验不确定的修改，可以创建分支进行，由于在Git上创建分支几乎零成本，git推荐创建分支来隔离修改。

Git可以很容易地对比两个分支，知道一个分支中哪些提交尚未合并到另一分支，反之亦然。

1.查看当前分支比other分支多了哪些提交$ git log other..

2.查看other分支比当前分支多了哪些提交$ git log ..other

SVN想做到这些不太容易。

2.Git可以实现更好的发布控制

针对同一个项目，Git可以设置不同层级的版本库（多版本库）， 或者通过不同的分支（多分支）实现对发布的控制。
• 设置只有发布管理员才有权限推送的版本库或者分支，用于稳定发布版本的维护。
• 设置只有项目经理、模块管理员才有权推送的版本库或者分支，用用于整合测试。

3.隔离开发，提交审核

如何对团队中的新成员的开发进行审核呢？在Git服务器上可以实现用户自建分支和自建版本库的功能， 这样团队中的新成员既能将本地提交推送到服务器以对工作进行备份， 又能够方便团队中的其他成员对自己的提交进行审核。

审核新成员提交时，从其个人版本库或个人分支获取（fetch）提交，从提交说明、代码规范、编译测试 等多方面对提交逐一审核。审核通过执行 git merge 命令合并到开发主线中。

4.对合并更好的支持，更少的冲突，更好的冲突解决
因为Git基于对内容的追踪而非对文件名追踪，所以遇到一方或双方对文件名更改时， Git能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突， 解决起来很麻烦。
Git的基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪， 避免不必要的冲突，提高工作效率。这是开发者选择Git、抛弃SVN的重要理由。

5.版本库的安全性

SVN版本库安全性很差，是管理员头痛的问题。
• SVN版本库服务器端历史数据被篡改，或者硬盘故障导致历史数据被篡改时， 客户端很难发现。管理员的备份也会被污染。
• SVN作为集中式版本控制系统，存在单点故障的风险。备份版本库的任务非常繁重。
Git在这方面完胜SVN。首先Git是分布式版本控制系统，每个用户都相当于一份备份， 管理员无需为数据备份而担心。再有Git中包括提交、文件内容等都通过SHA1哈希保证数据的完整性， 任何恶意篡改历史数据都会被及时发现从而被挫败。

更多的十条喜欢Git的理由

•    异地协同工作。
•    现场版本控制。
•    重写提交说明。
•    无尽的后悔药。
•    更好用的提交列表。
•    更好的差异比较。
•    工作进度保存。
•    作为SVN前端实现移动办公。
•    无处不在的分页器。
•    快。

什么情况推荐使用SVN

夸了这么多Git的优点，当然事实上也是如此，做开发还是拥抱Git吧。不过对于以二进制文件 （Word文档、PPT演示稿） 为主的版本库，为避免多人同时编辑造成合并上的困难， 建议使用SVN做版本控制。因为SVN具有的悲观锁的功能，能够实现一个用户在编辑时对文件进行锁定，阻止多人同时编辑 一个文件。这一悲观锁的功能是 Git 所不具备的。

总结

Git相比SVN优势还是挺明显的，由于SVN比Git早几年出现，在国内不少成熟(gubuzifeng)的团队还在使用SVN，Git这几年才在国内开始流行，并已经成为年轻团队代码管理必备了。SVN因为没有分支功能，所以对一般开发者而言可能使用起来更简单（对管理者而言可能会头疼），只需要GUI工具就基本能满足需求，而Git因为有强大的分支功能和修改保存功能等，团队代码管理规范的公司为了规范代码的管理需要每个开发者精确的使用Git分支能力,开发者因此需要掌握分支维护能力以及其他Git高级功能，这会增加普通开发者的学习成本。为了团队代码维护更好的，同时提高团队每个成员的开发效率，掌握git技能，放弃SVN拥抱Git是值得的。

为神马要关注提交信息(commit message)

• 加快 Reviewing Code 的过程
• 帮助我们写好 release note
• 5年后帮你快速想起来某个分支，tag 或者 commit 增加了什么功能，改变了哪些代码
• 让其他的开发者在运行 git blame 的时候想跪谢
• 总之一个好的提交信息，会帮助你提高项目的整体质量

基本要求

1. 第一行应该少于50个字。 随后是一个空行 第一行题目也可以写成：Fix issue #8976

喜欢用 vim 的哥们把下面这行代码加入 .vimrc 文件中，来检查拼写和自动折行
autocmd Filetype gitcommit setlocal spell textwidth=72

2. 永远不在 git commit 上增加 -m <msg> 或 --message=<msg> 参数，而单独写提交信息

一个不好的例子：

git commit -m "Fix login bug"

一个推荐的 commit message 应该是这样：

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user

3. 注释最好包含一个连接指向你们项目的 issue/story/card。一个完整的连接比一个 issue numbers 更好

4. 提交信息中包含一个简短的故事，能让别人更容易理解你的项目

注释要回答如下信息

• 为什么这次修改是必要的？

  要告诉 Reviewers，你的提交包含什么改变。让他们更容易审核代码和忽略无关的改变。

• 如何解决的问题？

这可不是说技术细节。看下面的两个例子：

Introduce a red/black tree to increase search speed

Remove <troublesome gem X>, which was causing <specific description of issue introduced by gem>

如果你的修改特别明显，就可以忽略这个。

• 这些变化可能影响哪些地方？

这是你最需要回答的问题。因为它会帮你发现在某个 branch 或 commit 中的做了过多的改动。一个提交尽量只做1，2个变化。

你的团队应该有一个自己的行为规则，规定每个 commit 和 branch 最多能含有多少个功能修改。

小提示

• 使用 fix, add, change 而不是 fixed, added, changed
• 永远别忘了第2行是空行
• 用 Line break 来分割提交信息，让它在某些软件里面更容易读
• 请将每次提交限定于完成一次逻辑功能。并且可能的话，适当地分解为多次小更新，以便每次小型提交都更易于理解。

例子

例子1.

Fix bug where user can't signup.

[Bug #2873942]

Users were unable to register if they hadn't visited the plans 
and pricing page because we expected that tracking    information 
to exist for the logs we create after a user signs up.  
I fixed this by adding a check to the logger
to ensure that if that information was not available
we weren't trying to write it.

例子2.

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user

本文参考阅读

A Note About Git Commit Messages

Writing good commit messages

Proper Git Commit Messages and an Elegant Git History

5 Useful Tips For A Better Commit Message

每个团队的开发流程各式各样，在工作中如何运用好git并不轻松。这个章节就尝试探究一下在公司团队中最最常用的git工作流。

在你阅读的时候，记住这些开发流主要用来做参考，而不是必须严格遵守，我们只是想展示主流的各种开发工作流让你了解，你应该融汇贯通的运用它们，并形成一个适合你们团队的开发流。

1. 集中式工作流

切换到分布式版本管理系统刚开始看起来困难，但你也可以不用改变你习惯的开发流就可以使用git，你团队可以像你使用SVN那样使用git进行开发。

不过使用Git作为开发的工作流，相比SVN有几个优势。 首先，每个开发者可以有整个项目的本地拷贝，隔离的环境让开发者们的工作和项目的其他部分修改独立开来 —— 开发者们可以提交代码到自己的本地仓库，可以完全忽略上游的开发，直到方便的时候再把修改推送到上游或者拉取上游的修改合并到本地。

其次，Git提供了强大的分支和合并模型。不像SVN，Git的分支成可以做为一种用来在仓库之间合并代码和交叉修改的”失败安全”的机制。

1.1. 如何进行

集中式工作流以中央仓库作为项目所有修改的唯一的入口，可以像SVN一样，Git业可以这么做。相比SVN缺省的开发分支trunk，Git叫做master，所有修改提交到这个分支上。本工作流除了使用master分支外不需要其他分支。

开发者先先克隆中央仓库，在自己的本地克隆项目中可以像SVN一样编辑文件和提交修改；但提交记录是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。

要发布修改到正式项目中，开发者要把本地master分支的修改推送（push）到中央仓库中，这相当于svn commit操作，不过push操作会将本地所有还没有提交到中央仓库的本地提交都推上去。

1.2. 解决冲突

中央仓库代表了正式项目，所以提交历史应该被严肃对待并且不应该修改提交历史。如果开发者本地的提交历史不是中央仓库历史提交派生（译者注：即开发者历史提交需要包含中央仓库的所有提交），Git会拒绝这种push推送，因为如果不这么设计的话这会覆盖已经在中央库的正式提交。

在开发者推送开发的功能到中央库前，他们需要先拉取（pull）中央库的新增提交，然后合并（rebase）自己的修改到中央库并显示在提交历史最顶部。 这样做的意思是在说：”我要把自己的修改加到别人已经完成的修改上“。最终的结果是一个完美的线性提交历史，这就像以前的SVN的工作流中一样。

如果本地修改和上游提交有冲突，Git会暂停rebase过程，需要你手动解决冲突。Git解决冲突非常方便，合并冲突和生成提交一样，使用git status和git add命令即可。而且，如果解决冲突时非常棘手，在Git中中止整个rebase操作轻而易举，然后重新来一次（或者找高手来帮助）。

1.3. 举例

让我们通过例子来一步步介绍在一个典型的小团队如何采用这个工作流来协作。有两个开发者小明（John）和小红（Mary），我们来看看他们是如何开发自己的功能然后提交到中央仓库上的。

1.3.1 第一步、先初始化好中央仓库

第一步，有人在服务器上创建好中央仓库。如果是新项目，你可以初始化一个空仓库；如果不是心项目，你可以导入已有的Git或SVN仓库。

中央仓库应该是个裸仓库（bare repository），即没有工作目录（working directory）的仓库。可以用下面的命令创建：

ssh user@host
git init --bare /path/to/repo.git

确保写上有效的user（SSH的用户名），host（服务器的域名或IP地址），/path/to/repo.git（你想存放仓库的位置）。 注意，为了表示是一个裸仓库，按照约定加上.git扩展名到仓库名上。

1.3.2. 第二步、所有人需要克隆（clone）刚创建的裸仓库

下一步，各个开发者创建整个项目的本地拷贝。通过git clone命令完成：

git clone ssh://user@host/path/to/repo.git

因为猜测未来你想要和克隆的仓库进行交互，克隆仓库时Git会自动添加远程别名origin指回”父“仓库。

1.3.3. 第三步、小明（John）着手开发新功能

小明在自己的本地仓库里能够使用标准的Git提交过程开发新功能：编辑、暂存（Stage）和提交。 如果你不熟悉暂存区（Staging Area），暂存区是用来准备一个提交，它允许你不把工作目录中所有的修改内容都包含进来， 尽管你本地修改很多内容，但暂存区让你可以创建一个高度聚焦（译者注：选择你希望提交到的修改）的提交。

git status          # 查看本地仓库的修改状态 
git add              # 暂存文件     
git commit        # 提交文件

记住，因为这些命令生成的是本地提交，小明想重复这个过程多少次就多少次，完全不用担心中央仓库发生了什么。 对较大的功能开发，我们可以将其拆分成一个一个简单的、小而完整的小功能，运用s这个过程很有用。

1.3.4. 第四步、小红（Mary）开发功能

与此同时，小红在自己的本地仓库中用相同的编辑、暂存和提交过程开发功能。和小明一样，她也不关心中央仓库； 也无须关心小明在他的本地仓库中的操作，因为所有本地仓库都是各玩各的。

1.3.5. 小明发布功能

一旦小明完成了他的功能开发，会发布他的本地提交到中央仓库中，这样其它团队成员可以看到他的修改。他可以用下面的git push命令：
git push origin master
记住，origin是在小明克隆仓库时Git创建的远程中央仓库别名，master参数告诉Git推送的分支。 由于中央仓库自从小明克隆以来还没有被更新过，所以push操作不会有冲突，推送将会顺利完成。

1.3.6. 小红试着发布功能

一起来看看在小明发布修改后，小红push修改会怎么样？她使用完全一样的push命令：

git push origin master

但她的本地历史已经和中央仓库有分歧（diverge）了，Git拒绝操作并给出下面乱七八糟的出错消息：

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

这避免了小红覆写中央仓库的正式提交。她要先拉取（pull）小明的更新到她的本地仓库合，然后合并她的本地修改，再重试推送。

1.3.7. 小红在小明的提交基础上合并（rebase）

小红用git pull合并上游的修改到自己的仓库中。 这条命令类似svn update——拉取所有上游提交命令到小红的本地仓库，并尝试和她的本地修改合并：

git pull --rebase origin master

–rebase选项告诉Git把小红的提交移到同步了中央仓库修改后的master分支的顶部，如下图所示：

如果你忘加了这个选项，pull操作仍然可以完成，但每次pull操作要同步中央仓库中别人修改时，提交历史会以一个多余的『合并提交』结尾。 对于集中式工作流，最好是使用rebase而不是生成一个合并提交。

1.3.8. 小红解决合并冲突

rebase操作是把本地提交一次性地转移到已经更新过的中央仓库master分支之上。 这意味着可能要解决在转移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时所出现的冲突。 这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。而且，找出引入Bug的地方也变的容易，如果有必要，可以回滚修改能保证对项目的影响最小。

如果小红和小明的功能是不相关的，不大可能在rebase过程中有冲突。如果有，Git在合并有冲突的提交处暂停rebase过程，输出下面的信息并带上相关的指令：

CONFLICT (content): Merge conflict in <some-file>

Git很赞的一点是，任何人可以解决他自己的冲突。在这个例子中，小红可以简单的运行git status命令来查看哪里有问题。 冲突文件列在Unmerged paths（未合并路径）一节中：

# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage)
# (use "git add/rm <some-file>..." as appropriate to mark resolution)
# both modified: <some-file>

接着小红编辑这些文件。修改完成后，用老套路暂存这些文件，并让git rebase完成剩下的事：

git add <some-file> 
git rebase --continue

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

如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行git pull –rebase命令前的样子：

git rebase --abort

1.3.9. 小红成功发布功能

小红完成和中央仓库的同步后，就能成功发布她的修改了：

git push origin master

如你所见，仅使用几个Git命令我们就可以模拟出传统Subversion开发环境。对于要从SVN迁移过来的团队来说这太好了，但没有发挥出Git分布式版本管理的天然优势。
如果你的团队适应了集中式工作流，但想要更流畅的协作效果，绝对值得探索一下_ 功能分支工作流 _的优点。 通过为一个功能分配一个分支，这样可以让在一个新增功能合并进正式项目之前向团队发起对新功能进行深入讨论称为可能。

2. 功能分支工作流

一旦你玩转了集中式工作流，在开发过程中加上功能分支可以方便地鼓励开发者之间协作和流畅地交流。
功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在master分支上。 这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。 另外，也保证了master分支的代码一定不会是有问题的，极大有利于持续集成环境。

隔离功能开发也让pull requests工作流成功可能， pull requests工作流能为每个分支合并发起一个讨论，在其它开发者有表示赞同之后才可以合并进正式项目。 另外，如果你在功能开发中有问题卡住了，可以开一个pull requests来向同学们征求建议。 这些做法的重点就是，pull requests让团队成员之间互相评论工作变成非常方便！

2.1. 如何进行

功能分支工作流仍然才用中央仓库，并且master分支还是代表了正式项目的历史。 但不是直接提交本地历史到各自的本地master分支，开发者每次在开始新功能前先创建一个新分支。 功能分支应该有个有描述性的名字，比如animated-menu-items或issue-#1061，这种做法可以让每个分支有清晰明确目的。

master分支和功能分支，对Git来说没有技术上的区别，所以开发者可以用和集中式工作流中完全一样的方式编辑、暂存和提交修改到功能分支上。

另外，功能分支也可以（且应该）push到中央仓库中。这样不修改正式代码就可以和其它开发者分享提交的功能。 由于master是仅有的一个特殊分支，在中央仓库上存多个功能分支不会有任何问题。当然，这样做也可以很方便地备份各自的本地提交。

2.2. 合并申请（Pull Requests）

功能分支除了可以隔离功能的开发，也使得通过合并申请 （Pull Requests）讨论变更成为可能。 一旦某个开发者完成一个功能，不是立即合并到master，而是推送（push）到中央仓库的对应的功能分支上，然后发起一个合并申请（Pull Request）请求合并他的修改到master分支。 在修改成为主干代码前，这让其它的开发者有机会先去Review变更。

Code Review是Pull Requests的一个重要的优点，但Pull Requests设计的真正初衷是为了交流和讨论代码。 你可以把Pull Requests作为专门给某个分支的一次讨论。这意味着可以在更早的开发过程中就运用pull requests。 比如，一个开发者开发功能需要帮助时，要做的就是发起一个Pull Request，感兴趣的人就会自动收到通知，在相关的提交旁边能看到提出的问题。

一旦Pull Request被接受了，发布功能要做的就和集中式工作流就很像了。 首先，确定本地的master分支和上游的master分支是同步的。然后合并功能分支到本地master分支并push已经更新的本地master分支到中央仓库。

pull request 可以运用在仓库管理的产品解决方案提供商，像Bitbucket云。你可以从Bitbucket的Pull Requests文档中找找例子。

2.3. 示例

下面的示例演示了如何把Pull Requests作为Code Review的方式，但注意Pull Requests可以用于很多其它的目的。

2.3.1. 小红开始开发一个新功能

在开始开发功能前，小红需要一个独立的分支。使用下面的命令新建一个分支：

git checkout -b marys-feature master

这个命令检出一个基于master名为marys-feature的分支，Git的-b选项表示如果分支还不存在则新建分支。 这个新分支上，小红按老套路编辑、暂存和提交修改，按需要提交以实现功能：

git status
git add <some-file>
git commit

2.3.2. 小红要休息去吃个午饭

早上小红为新功能添加一些提交。 去吃午饭前，push功能分支到中央仓库是很好的做法，这样可以方便地备份，如果和其它开发协作，也让他们可以看到小红的提交。

git push -u origin marys-feature

这条命令push marys-feature分支到中央仓库（origin），-u选项设置本地分支去跟踪远程对应的分支。 设置好跟踪的分支后，小红就可以使用git push命令省去指定推送分支的参数。

2.3.3. 小红完成功能开发

小红吃完午饭回来后，并完成了她的功能的开发。在合并到master之前， 她发起一个Pull Request让团队的其它人知道功能已经完成。但首先，她要确认中央仓库中已经有她最近的提交：

git push

然后，在她的Git GUI客户端中发起Pull Request，请求合并marys-feature到master，团队成员会自动收到通知。Pull Request很酷的是可以在相关的提交旁边显示评注，所以你可以对某个变更集进行提问。

2.3.4. 小贝(Bill)收到Pull Request

小贝收到了Pull Request后会查看marys-feature的修改。决定在合并到正式项目前是否要做些修改，且通过Pull Request和小红来回地讨论。

2.3.5. 小红再做修改

要再做修改，小红用和功能第一个迭代完全一样的过程。编辑、暂存、提交并push更新到中央仓库。小红这些活动都会显示在Pull Request上，小黑可以继续做评注。

如果小黑有需要，也可以把marys-feature分支拉到本地，自己来修改，他加的提交也会一样显示在Pull Request上。

2.3.6. 小红发布她的功能

一旦小黑可以的接受Pull Request，就可以合并功能到稳定项目代码中（可以由小黑或是小红来做这个操作）：

git checkout master
git pull
git pull origin marys-feature
git push

无论谁来做合并，首先要检出master分支并确认是它是最新的。然后执行git pull origin marys-feature合并marys-feature分支到和已经和远程一致的本地master分支。 你可以使用简单git merge marys-feature命令，但前面的命令可以保证总是最新的新功能分支。 最后更新的master分支要重新push回到origin。

这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交，因为它像一个新功能和原来代码基线的连通符。 但如果你偏爱线性的提交历史，可以在执行合并时rebase新功能到master分支的顶部，这样生成一个快进（fast-forward）的合并。

一些GUI客户端可以只要点一下『接受』按钮执行好上面的命令来自动化Pull Request的合并过程。 如果你的客户端没有这个功能，记得在功能合并到master分支后关闭Pull Request。

2.3.7. 与此同时，小明在做和小红一样的事

当小红和小黑在marys-feature上工作并讨论她的Pull Request的时候，小明在自己的功能分支上做完全一样的事。

通过隔离功能到独立的分支上，每个人都可以自主的工作，当然这跟在必要的时候让变更开发者之间交流分享的作用比微不足道。

2.4. 下一步该做什么呢？

到了这里，但愿你发现了功能分支可以成倍提高 仅有master分支的集中式工作流的实用性。 另外，功能分支还使用了Pull Request，使得可以在你的版本控制GUI客户端中讨论某个提交。

功能分支工作流是开发项目异常灵活的方式。问题是，有时候太灵活了。对于大型团队，常常需要给不同分支分配一个更具体的角色。 Gitflow工作流是管理功能开发、发布准备和维护的常用模式。

3. Gitflow工作流

Gitflow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

这节介绍的Gitflow工作流借鉴自Vincent Driessen写的《A successful Git branching model》。

Gitflow工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于管理大型项目的最佳框架。

Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。 除了使用功能分支，在准备期、维护期和予发布期各使用了单独的分支。 当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。

3.1 如何进行

Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要中央仓库中。

3.1.1 历史分支

相对使用仅有的一个master分支，Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的合并汇合分支。 这样也方便master分支上的所有提交分配一个版本号。

剩下要说明的问题围绕着这2个分支的区别展开。

3.1.2. 功能分支

每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。

注意：从各种含义和目的上来看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流没有在这里止步。

3.1.3. 发布分支

一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。

使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，“这周我们要做准备发布版本4.0”，并且在仓库的目录结构中可以实际看到）。
常用的分支约定：

用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release- 或 release/

3.1.4. 维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

为紧急Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

3.2. 示例

下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。

3.2.1. 创建开发分支

第一步为master分支配套一个develop分支。简单来做可以本地创建一个空的develop分支，push到服务器上：

git branch develop
git push -u origin develop

以后这个分支将会包含了项目的全部历史，而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库，建好develop分支的跟踪分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

现在每个开发都有了这些历史分支的本地拷贝。

3.2.2. 小红和小明开始开发新功能

这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支，而是应该基于develop分支：

git checkout -b some-feature develop

他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：

git status
git add <some-file>
git commit

3.2.3. 小红完成功能开发

添加了提交后，小红觉得她的功能OK了。如果团队使用Pull Requests，这时候可以发起一个用于合并到develop分支的请求。 否则她可以直接合并到她本地的develop分支后push到中央仓库：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令在合并功能前确保develop分支是最新的。注意，功能决不应该直接合并到master分支。 冲突解决方法和集中式工作流一样。

3.2.4 小红开始准备发布

这个时候小明正在实现他的功能，小红开始准备她的第一个项目正式发布。 像功能开发一样，她用一个新的分支来做发布准备。这一步也确定了发布的版本号：

git checkout -b release-0.1 develop
这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。
只要小红创建这个分支并push到中央仓库，这个发布就是功能冻结的。任何不在develop分支中的新功能都推到下个发布循环中。

3.2.5 小红完成发布

一旦准备好了对外发布，小红合并修改到master分支和develop分支上，删除发布分支。合并回develop分支很重要，因为在发布分支中已经提交的重要更新需要在后面的新功能中也要是可用的。 另外，如果小红的团队要求Code Review，这是一个发起Pull Request的理想时机。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

发布分支是作为功能开发（develop分支）和对外发布（master分支）间的缓冲。只要有合并到master分支，就应该打好Tag以方便跟踪。

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git有提供各种勾子（hook），即仓库有事件发生时触发执行的脚本。 可以配置一个勾子，在你push中央仓库的master分支时，自动构建好对外发布。

3.2.6 终端用户发现Bug

对外发布后，小红回去和小明一起做下个发布的新功能开发，直到有终端用户开了一个Ticket抱怨当前版本的一个Bug。 为了处理Bug，小红（或小明）从master分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回master分支：

git checkout -b issue-#001 master
Fix the bug
git checkout master
git merge issue-#001
git push

就像发布分支，维护分支中新加这些重要修改需要包含到develop分支中，所以小红要执行一个合并操作。然后就可以安全地删除这个分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

到了这里，但愿你对集中式工作流、功能分支工作流和Gitflow工作流已经感觉很舒适了。 你应该也牢固的掌握了本地仓库的潜能，push/pull模式和Git健壮的分支和合并模型。

记住，这里演示的工作流只是可能用法的例子，而不是在实际工作中使用Git不可违逆的条例。 所以不要畏惧按自己需要对工作流的用法做取舍。不变的目标就是让Git为你所用。

4. Forking工作流

Forking工作流是分布式工作流，充分利用了Git在分支和克隆上的优势。可以安全可靠地管理大团队的开发者（developer），并能接受不信任贡献者（contributor）的提交。

Forking工作流和前面讨论的几种工作流有根本的不同，这种工作流不是使用单个服务端仓库作为中央代码库，而让各个开发者都有一个服务端仓库。这意味着各个代码贡献者有2个Git仓库而不是1个：一个本地私有的，另一个服务端公开的。

Forking工作流的一个主要优势是，贡献的代码可以被合并，而不需要所有人都能push代码到仅有的中央仓库中。 开发者push到自己的服务端仓库，而只有项目维护者才能push到正式仓库。 这样项目维护者可以接受任何开发者的提交，但无需给他正式代码库的写权限。

效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。 也让这个工作流成为开源项目的理想工作流。

4.1 如何进行

和其它的Git工作流一样，Forking工作流要先有一个公开的正式仓库存储在服务器上。 但一个新的开发者想要在项目上工作时，不是直接从正式仓库克隆，而是fork正式项目在自己的服务器上创建一个拷贝。

这个仓库拷贝作为他个人公开仓库 —— 其它开发者不允许push到这个仓库，但可以pull修改（后面我们很快就会看这点很重要）。 在创建了自己服务端拷贝之后，和之前的工作流一样，开发者执行git clone命令克隆仓库到本地机器上，作为私有的开发环境。

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

为了集成功能到正式代码库，维护者pull贡献者的变更到自己的本地仓库中，检查变更以确保不会让项目出错， 合并变更到自己本地的master分支， 然后推送master分支到服务器的正式仓库中。 到此，贡献的提交成为了项目的一部分，其它的开发者应该执行pull操作与正式仓库同步自己本地仓库。

4.2.1. 正式仓库

在Forking工作流中，正式仓库的叫法只是一个约定，理解这点很重要。 从技术上来看，各个开发者仓库和正式仓库在Git看来没有任何区别。 事实上，让正式仓库之所以正式的唯一原因是它是项目维护者的公开仓库。

4.2.2. Forking工作流的分支使用方式

所有的个人公开仓库实际上只是为了方便和其它的开发者共享分支。 各个开发者应该用分支隔离各个功能，就像在功能分支工作流和Gitflow工作流一样。 唯一的区别是这些分支被共享了。在Forking工作流中这些分支会被pull到另一个开发者的本地仓库中，而在功能分支工作流和Gitflow工作流中是直接被推送到正式仓库中。

4.3 示例

4.3.1. 项目维护者初始化正式仓库

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

公开仓库应该是裸仓库，不管是不是正式代码库。 所以项目维护者会运行像下面的命令来搭建正式仓库：

ssh user@host
git init --bare /path/to/repo.git

Bitbucket提供了一个方便的GUI客户端以完成上面命令行做的事。 这个搭建中央仓库的过程和前面提到的工作流完全一样。 如果有现存的代码库，维护者也要push到这个仓库中。

4.3.2 开发者fork正式仓库

其它所有的开发需要fork正式仓库。 可以用git clone命令用SSH协议连通到服务器， 拷贝仓库到服务器另一个位置 —— 是的，fork操作基本上就只是一个服务端的克隆。 Bitbucket和Stash上可以点一下按钮就让开发者完成仓库的fork操作。

这一步完成后，每个开发都在服务端有一个自己的仓库。和正式仓库一样，这些仓库应该是裸仓库。

4.3.3. 开发者克隆自己fork出来的仓库

下一步，各个开发者要克隆自己的公开仓库，用熟悉的git clone命令。

在这个示例中，假定用Bitbucket托管了仓库。记住，如果这样的话各个开发者需要有各自的Bitbucket账号， 使用下面命令克隆服务端自己的仓库：

git clone https://user@bitbucket.org/user/repo.git

相比前面介绍的工作流只用了一个origin远程别名指向中央仓库，Forking工作流需要2个远程别名 —— 一个指向正式仓库，另一个指向开发者自己的服务端仓库。别名的名字可以任意命名，常见的约定是使用origin作为远程克隆的仓库的别名 （这个别名会在运行git clone自动创建），upstream（上游）作为正式仓库的别名。

git remote add upstream https://bitbucket.org/maintainer/repo

需要自己用上面的命令创建upstream别名。这样可以简单地保持本地仓库和正式仓库的同步更新。 注意，如果上游仓库需要认证（比如不是开源的），你需要提供用户：

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

这时在克隆和pull正式仓库时，需要提供用户的密码。

4.3.4. 开发者开发自己的功能

在刚克隆的本地仓库中，开发者可以像其它工作流一样的编辑代码、提交修改和新建分支：

git checkout -b some-feature
Edit some code
git commit -a -m "Add first draft of some feature"

所有的修改都是私有的直到push到自己公开仓库中。如果正式项目已经往前走了，可以用git pull命令获得新的提交：

git pull upstream master

由于开发者应该都在专门的功能分支上工作，pull操作结果会都是快进合并。

4.3.5. 开发者发布自己的功能

一旦开发者准备好了分享新功能，需要做二件事。 首先，通过push他的贡献代码到自己的公开仓库中，让其它的开发者都可以访问到。 他的origin远程别名应该已经有了，所以要做的就是：

git push origin feature-branch

这里和之前的工作流的差异是，origin远程别名指向开发者自己的服务端仓库，而不是正式仓库。
第二件事，开发者要通知项目维护者，想要合并他的新功能到正式库中。 Bitbucket提供了Pull Request按钮，弹出表单让你指定哪个分支要合并到正式仓库。 一般你会想集成你的功能分支到上游远程仓库的master分支中。

4.3.6. 项目维护者合并开发者的功能

当项目维护者收到pull request，他要做的是决定是否集成它到正式代码库中。有二种方式来做：

1. 直接在pull request中查看代码
2. pull代码到他自己的本地仓库，再手动合并

第一种做法更简单，维护者可以在GUI中查看变更的差异，做评注和执行合并。 但如果出现了合并冲突，需要第二种做法来解决。这种情况下，维护者需要从开发者的服务端仓库中fetch功能分支， 合并到他本地的master分支，解决冲突：

git fetch https://bitbucket.org/user/repo feature-branch
git checkout master
git merge FETCH_HEAD

变更集成到本地的master分支后，维护者要push变更到服务器上的正式仓库，这样其它的开发者都能访问到：

git push origin master

注意，维护者的origin是指向他自己公开仓库的，即是项目的正式代码库。到此，开发者的贡献完全集成到了项目中。

4.3.7. 开发者和正式仓库做同步

由于正式代码库往前走了，其它的开发需要和正式仓库做同步：

git pull upstream master

如果你之前是使用SVN，Forking工作流可能看起来像是一个激进的范式切换（paradigm shift）。 但不要害怕，这个工作流实际上就是在功能分支工作流之上引入另一个抽象层。 不是直接通过单个中央仓库来分享分支，而是把贡献代码发布到开发者自己的服务端仓库中。

示例中解释了，一个贡献如何从一个开发者流到正式的master分支中，但同样的方法可以把贡献集成到任一个仓库中。 比如，如果团队的几个人协作实现一个功能，可以在开发之间用相同的方法分享变更，完全不涉及正式仓库。

这使得Forking工作流对于松散组织的团队来说是个非常强大的工具。任一开发者可以方便地和另一开发者分享变更，任何分支都能有效地合并到正式代码库中。

原文出处

《Comparing Workflows》

30岁生日将至，孔子说三十而立，对于这个“立”字的理解现代人的理解不尽相同，每个人的人生际遇不同，自然到这个年龄每个人的情况和心态也也不尽相同，自然有每个人的理解。身边不少同龄人有车有房，娶妻生子，对此我甚是难看啊，这几样我都没沾边，女友鄙视过了，老家盖了房不算没屁用，Come On。实际的东西没有，只能给自己写点虚的，事实我就是这么理想主义，上帝也是公平的，只会给你想要的，他老人家看我屌丝样，所以就没打算给我房车。

28岁之前我一直在国企里工作，毕业之后又幸也不幸地加入首都高速公路发展集团旗下的北京云星宇交通工程有限公司，这是一家老派的国企，有我们体制外的人认为的国企各种效率低下和内部管混乱的问题。我在那里做了一年asp.net，开发了两个小项目，项目开发完之后，公司领导也不太可能让我就这么呆着，看我技术能力不错，领导就让我参与支持各个高速公路收费站的DB2的数据库运维工作。我因为在加入公司不久后，看到的企业里出现的各种问题超出我当时的认知范围，慢慢患上了社交恐惧和抑郁症（当时意识到自己有毛病，但不太清楚什么病），后来病情慢慢好转许多之后，在这家单位工作快两年后，在2011年5月份裸辞休息了四个月左右，期间去全国一些名胜古迹转了转，顺便考了一次托福。

11年国庆之后，我加入了一家算是难得优秀的国企吧——深圳证券交易所控股的深圳证券通信有限公司，在公司里负责机房的系统和网络的软硬件环境的运维。公司内部管理跟我之前呆的国企截然不同，真有地狱和天堂的这种级别的差异，公司管理制度比较规范，同事之间也比较友善和互相包容，而且工作清闲自在，你有足够的时间去做自己的事情，玩点兴趣爱好，有各种兴趣爱好的社团，公司才三四百号人就有各式人才，有书法很牛的，有写词作诗出神入化的，有舞蹈厉害的，有摄影厉害的，有打网球厉害的，有打篮球厉害的……。这家公司对我当时还没完全摆脱抑郁的状态是非常合适的，我有大把时间去看书，去尝试新鲜事物，去瞎琢磨人生的意义什么（在那几年里这是我认为最重要的事情，嗯）。在这家公司专业上收获不多，但是业余时间我看了不少书，电子的加纸质的100本不止，各种心灵鸡汤的，灵修学的，宗教学的，当然也有其他专业的涉猎，去过中国不少的名山名城，也学会了滑雪啊，打网球等收益一辈子的体育爱好。到14年初，我发现像我这种不能依靠父母买车买房的人是不太有资格过神仙日子的，其实也不错啊，还好过了几年，没过过也挺可惜的，真的很爽的，除了有时候闲的只能胡思乱想，偶尔年轻人会迷茫迷茫外。所以14年春节回来后我就琢磨要摆脱这个舒适区，到了该改变的时候了，开发App当时是我觉得最酷最想做的事情。

在深证通我有的就是时间，14年春节后我上班时间在学写代码，下班时间也是在写代码，自学期间独立完成了几个App，后来为朋友的公司开发了一个小型商业App之后，15年我正式转行担任高级iOS开发一直到现在，在小公司干过小1年做了两个项目，在一家正规军的大团队干了一年做了一个大项目，现在在平安负责一个iOS项目，刚开发完第一版。从14年初到现在，我每天应该14个小时用在做iOS有关的事情，而且周末也是在做公司的项目或者自己的个人项目，一年应该有320天以上如此吧。多次被女友嫌弃到差点抛弃，还好女友善良仁慈，我才得以逃过被休的命运。按照10000小时的定律来看，我粗略的算了我这近三年在iOS上所花的时间已经超了这个数了。和同行们交流多了，我大概已经知道自己在iOS领域是一个什么水平，我用了3年时间，从一个iOS的入门汉已经成长为在iOS方向无所畏惧的开发者了。

再回头看，我干过1年多的后端，干过小1年的DB2数据库管理员，干了3年的Linux系统和思科网络管理员，然后又干了近三年的iOS开发，在大公司呆过，在小团队干过，在好公司感受到过团队开发合作流的美好，也在烂公司经历过各种痛苦，在团队里合作开发过项目，也有过从盗图设计到产品构思到数据库设计到app研发的独立开发App的经历。在我做iOS开发的这三年里，我也时常收益于我之前的工作经历，比如和后端沟通的时候我很能理解他们是如何实现的，能理解他们的难处，也能给他们一些合理的建议，我也非常关注项目的可维护性和可括扩展性，因为我有运维人员的思维，也理解运维人员痛点，希望做的项目尽可能是可维护可读性高的可扩展的。我能站在一个项目生命周期上整体上去思考立项、研发、运维、迭代等的工作如何进行如何规划会让所有环节的工作开展顺利流畅。我毕业后的7年多，经历很多困难，但同时也让我参与互联网行业的不少工种，让我成为一个技术能力比较综合的互联网从业者，上天真TM确实是公平的，你有机会经历九九八十一难，就能收获多少份真经，少一难你也就少取得一份真经。

农村出身的我，初中才有机会在暑假去县城工作的姐姐那玩去过一次县城，然后高中在县城念了三年书，在高中期间因为参加一次考试去过省城，大学去省城读了4年，大学毕业旅行去了趟四川重庆，算是第一次跨过一次省吧，毕业之后就想来首都见识见识就来了北京，然后就在首都苦逼了7年多。我的成长轨迹，自然而然我心里种下了一颗信念的种子，我相信自己这样努力下去，迈着迈着就会来到更大的舞台，见识更大的世界。信念一旦种下，想挡也都挡不住😄。

人到三十，蛮尴尬的，混的好与不好的开始拉开段位。从现实成就上看，我目前还不算一个做的好的（真不想承认是差的啊），但从阿Q精神状态上看，我觉得自己还是蛮不错的。三十岁之后的我要用自己的能力、努力、牛逼的态度去创造价值去收获成绩：做一两款有名的优秀产品，多写点文章总结反思，有机会出一两本书，走狗屎运的话希望能带着一个团队做这些事情。同时也该有点物质追求了：结婚生子买房买车（求亲朋好友大款赞助）。

1.关于移动端对用户输入的校验

iOS和android的同事就移动端用户输入是否需要校验，以及用户输入是否需要更强的校验有不同的看法，争论的时候没有找到共通点，所以不了了之了。

现在想想我们其实都同意移动端适合弱校验、问题主要是在什么是弱校验上有分歧。android同事倾向于很弱的校验，比如手机号码只限制11位的最多数字，身份证只校验最大输入18位，他们认为这样即使未来手机号码段增加客户端也不会有校验通不过的风险。他们理由确实有道理，不能让客户端校验无法通过阻碍用户使用我们是有共识的。不过如果服务器端没做校验呢？比如用户输入一个非法的手机号，服务端确没有得到正确的反馈这也不太好，即使如果服务器端做了校验，那也是在发出请求loading一段时间之后给的用户反馈，这浪费了用户流量也浪费了用户时间，从用户体验的角度看，这是不太友好的。那如何平衡用户体验和功能可用性，提高用户体验同时又能保证功能可用？这是进一步思考的问题。为了保证这两点，我觉得对弱校验的弱需要做一点点增强，因为移动互联网发展特别快，手机更新换代也很快，软件升级发展更快，基本一两个月就会有一版，所以保证可预见的时间内产品可用就行了，比如两三年，这样的话我们就可以对一些数据的校验能不能更严格有一个判断，比如身份证我们完全可以做一个强校验，身份证号码是有一套严格的规则的，未来很长时间也不会有变化，完全可以更强的校验，在用户输入错误时，移动端提前就给用户输入错误以正确的用户提示，而不是在提交服务器后才得到反馈，作为用户的角度应该更容易接受，用户有这个心理预期。其他诸如银行卡，邮箱也都是可以做强校验的。至于一些在可预见的时间内会有些变化的输入，比如用户手机号码，可能未来号段会增加，我们可以预测下未来的几年可能会增加的号段，其实短时间号段也不会太大变化的，对于这种可能会变化的输入校验，就需要我们有一个更准确的评估，我们在客户端可以适当校验放松一点，但必要的校验还是要的，至少校验用户手机号码输入是1开头的11数字位是可以做的，甚至判断下第二位是在3、5、6、7、8中选一个数字也是可以做的。在保证用户体验的同时做一些必要的加强版弱校验还是必要的。

在一些技术和产品边界点，也许更考验一个团队的整体价值观了，一切都要从我们做产品的初心去思考，我们都希望做用户体验最极致的产品，我们都希望做功能最可靠的产品，都希望产品的效益最大化。回到初心之后，我们就需要一步一步的去规划，如何兼顾长期目标和短期目标，然后再去去了解团队现状，比如团队的能力是什么样子，团队开发的产品的迭代周期是多久，市场整体的发展状况是怎样等。

2.关于项目的横向依赖问题

最近因为几个bug搞得很郁闷，有几个类似的bug从界面上看android展示的比iOS友好，比如iOS一个详情页没有展示产品名称，而android却展示了，所以产品和测试就有足够的理由说iOS做的不对了，认为iOS端出了一个这么不友好且低级的bug，问题报给我们，我们肯定也觉得自己写的代码有问题导致差异。然而最后定位问题发现是后端没有返回产品名称，所以导致iOS 客户端无法展示，但是android为什么能展示呢，询问他们之后，他们告诉我android从前面的列表页面带过来了产品名称，我因此想起还有几个bug开给iOS，是因为android跨页面带入了数据导致。

从我的技术直觉上我不太理解这种做法，因为这样没完没了的横向带入不必要数据增加了类之间的横向依赖和耦合性，这不符合软件设计的基本原则：高内聚，低耦合。这种做法让代码里多了一些数据正常情况下不需要的判断逻辑，这无疑会增加代码的可维护性可阅读性的成本，也让类的迁移和更改带来成本。但android给人的效果确实好，所以这类bug对于iOS端来说改与不改都难受，不改的话就只能等着后端改好，后端会因为改bug的时间较长，而android做了兼容，后端同事会建议iOS端是否也可以参考带入先保证app工作，同时产品测试更是会催着你赶紧改好，然而改的话又觉得对不起自己做的技术架构和做技术运用的原则，iOS App是尽最大努力减少类之间的横向依赖，让项目中的类保持独立性，这样做符合软件设计的原则的，代码更简洁，我们以后的架构还会设计一个底层参数池的中间件，帮助类与类之间交换数据和通信，这样类之间的横向依赖问题会得到更好的解决，所以我不太愿意为了改一个bug，而牺牲代码质量和技术架构。最后我做了妥协，很郁闷。

关于这个问题android和iOS端处理方式的不同，android的做法保证了产品的健壮性，从产品的角度大家都是乐于看到的，但是从技术的角度，这样做其实是不太恰当，让代码质量变差了，是不太利于后期维护的。从发展的角度来说，后端应该解决这个bug，因为这种bug不解决是有点说不过去的，移动端为后端做这样的保护不太必要，首先这样的话两个客户端都需要做这种处理，增加了成本，其二这种问题早点暴露，还是有利于前后端解决好问题的。

这类bug的不同处理方式还引起我的更深层次的思考，我们作为程序员应该是技术导向的思维方式还是应该产品导向的思维方式？如何让技术人员兼顾这两种思维？兼顾这两者最佳的点在哪里？哪些地方需要做好健壮性保护，哪些地方由应该互相信任。一款产品的成功应该需要大家的通力协作，团队的每个环节都需要做到最好。

3.关于后端交付何种格式的数据给移动端

我们在项目过程中，还遇到了不少后端提供哪种格式的数据给移动端的问题，比如返回null导致iOS崩溃问题。

从后台的角度来说，api中返回的数据中，正确值和空值的类型必须一样，举例，用户名的字段是“realname”: “xxx”,如果用户名为空，则应该返回“realname”: “”。如果返回值是一个array，空数据则返回一个空array，绝对禁止null值。对于客户端，必须用个全局的函数来处理所有api的返回数据，需要有一个机制：对于某个客户端需要数据，如果api中缺失，客户端自动补上并给予默认值。这个机制在我们的实践中大大减少了app的闪退。

再比如返回时间数据问题。有同事认为将需要移动端计算的时间后端可以用长整型时间给到移动端，移动端计算后再处理用来回传或展示，而展示性的数据则由后端处理直接交给移动端展示，也有像我认为的同事，把这种格式化的问题交给移动端，后段提供统一的时间戳的格式给客户端就好，让事情变的统一一致。类似的问题还有金额问题，金额有些地方需要显示5000元，有些地方需要显示5万元，到底后端是直接给我们5万这个字符串让移动端直接展示好呢，还是给我们50000这个数字，移动端处理后再展示好呢。

这个问题其实不是什么大问题，把格式化放在后端可以让我们更容易控制，因为如果需要展示不同格式数据时，我们只需要修改后端就好，否则就需要客户端发布新版本，但是这样子也带来一些问题，让后端开发需要关注移动端页面展示的细节来定义接口文档，并且让接口返回的数据格式不统一，比如有些接口返回年月日，有些地方返回月日等，这其实不利于数据的标准化管理。把格式化放在移动端的话，会带来发布版本的成本，但却可以让接口文档更清晰，遇到时间和金额的数据的时候就知道接口返回的格式。

我个人倾向于后端应该是一个管道的角色，负责数据的增删改查组合分离等，后端专注于做大接口的提供方，而不是为了微观的事情改代码，这可能会引起更大的问题，比如后端修改后的部署对用户的影响是更大的，而把如果把数据的加工处理工作交给移动端处理，这样分工更清晰，虽然这样子的修改可能需要发版，但是这类小问题的完全可以积攒到一个大版本再发，其实也不太影响发版，不过可能会让不同版本的app的展示有些微小的不一致，用户一般一个平台都只有一个手机，即使有多个不同手机，展示的一点不一致，用户应该也是可以接受的。我个人认为这样做对项目长期可维护是有好处，当然这是一家之言，最后还是应该实践检验真知吧。

事物的存在都是有两面性的，技术选型也是如此。看来在技术运用和产品的实现上，价值观是一个很重要的，不忘初心，理清思路，方能设计一个一致性很强的技术项目，帮助实现产品的效益的最大。

​前几天在微博上，看到有猿友转发了著名的开源消息管理平台zeroMQ的作者Pieter Hintjens安乐死的消息，作者简单在twitter发布了个消息，写了几个字：I’m choosing euthanasia etd 1pm.I have no last words.（我在下午一点选择了安乐死，我没有遗憾）。 作者如此平静和自信的离开，让我非常震惊和好奇，于是找到他的博客拜读了他的一系列文章。这篇文章是他被诊断胆管癌后写下的第一篇文章，讲述了作者对面对死亡的态度和做法，实在太有感动了，这篇文章有一篇台湾人的繁体翻译，不过放在facebook上，而且翻译不是特别好，所以我决定在它的基础上修改，希望给自己未来持续拜读以及有缘之人看到。

原文出处：A Protocol for Dying 繁体翻译出处

这是我的最后一篇文章（不是真的，后来作者还写几篇）。或许我可以多写几篇，但是有太多事情要去处理了，写完这个，我得选个最舒适的卧床姿势，去专注和病痛斗争以及陪伴我的家人了。

昨天有12个朋友来看我，包括我几个可爱的小孩，你可能会想这么多人来会累个半死，然而络绎不绝的朋友跟家人来访对我而言，就像一场奢华的，无限量供应新鲜热水的泡澡，棒极了。

我曾经是一个与社会断绝联繫又孤单的年轻人，也许有点自闭，心中只有工作、游泳跟几只猫。对于「跟其他人跟在一起会感到快乐」这种想法感到奇怪，不过我的工作还算有点价值，至少我自己是这么想的。我们用Cobol语言写过代码生成器，我写的编辑器在公司中很快受欢迎，因為它运作的非常好，而且能在我们所有的系统平台上执行。我自学C跟8086汇编，还写过几个工具性的共享软件。我就是这样慢慢地度过了90年代。

久而久之我发现如果跟陌生人交谈，任何形式的互动过程（例如买热狗、或者买东西）对方都会愉快地回应，这让我对交谈上了瘾，就像那些喝咖啡慢慢上癮的人一样。

它逐渐变成了日常，然后又变成我工作的目地：到陌生的地方去见不同的人。我喜欢参加研讨会，因為在那裡找人讲话不需要想借口，每个人都喜欢而且想要讲话。我很少在那里讨论技术性议题。如果你想讨论技术的话，可以去读代码。

因為这样，这几十年来我很自豪我的主要工作就是跟人谈话、听他们说话、彼此交流知识，然后综合起来再分享给其他人。我总共在欧洲、美洲、非洲与亚洲做了上千场交流，任何人赞誉我有创意、聪明，我都欣然接受。其实那些我曾提出的观点原型或理论，一直都是从有现实生活经验的人们那发掘出来的。

感谢你们，我的朋友们，因為你们才有那些。当我说 ” 我爱你们 ” 时，那不是一种姿态。我一直从你们身上获取给养，包括专业和思想。

今天，我要记录最后一个观点原型，它是关于如何面对死亡的。但是这篇文章不是RFC:)

发生什么事了呢？

从专业技术上来讲，我所罹患的胆管癌已经转移到左右的肺部。从二月份开始干咳，疲惫感越来越沈重，以致无法专心工作。三月份我父亲过世我们忙进忙出办理他的后事时，咳嗽一直伴随着我。4月8日我跟我的肿瘤医生说我非常不舒服，她替我安排了紧急的CAT扫描跟抽血检验。

4月13日做了恐怖的内视镜及切片，4月15日做正子断层扫描(PET Scan)，4月16日本来我打算开车到Eindhoven去NextBuild公司演讲，没去成反而是进了急诊室，切片那一侧有剧痛，打了抗生素之后疼痛才感到纾解。4月18日肿瘤科医生确认是癌症转移，我无法出院得要继续留下来，我的主治大夫正在考虑要进行怎样的化疗，我罹患的癌症在欧洲病例不多，相关资料很少。

我们所确知的是胆管癌对化疗的反应不佳，而且我身上的癌症攻击性很强而且移动得很快，第三，身体其它地方（肺部）已经发现有癌症转移，这些都是清清楚楚的具体资料。

所以，那一天我对外公开了这个讯息，并准备面对死亡。

如何与临终者交谈

与临终者谈话可能很艰辛，我们暂时称这个将死之病人为Bob，探病的人称为Alice，以下几点是Alice不应该对Bob说的：

1. ”撑著点！你必须保持希望，你必须击败它！” ，你要假设 「Bob已经尽力去击败病魔了」，这个假设不会错的，就算他没有，那也是他的选择。
2. ”我好难过，你不能死”，我女儿曾对我讲过这句话，我当时跟她说这是无可争论的现实，死亡是不允许我们选择的。对事实生气或难过是在浪费时间，无法改变事实。
3. ”你一定可以打败它！不试怎么知道” ，这是Alice在表达她的期望。但错误的期望不是治疗，好的化疗药剂或者解痛剂才是。
4. “好像还有一些偏方”，这句话让我很想拿鎚子，还好对我讲这种话的人不多。就算真有奇迹，也要考虑费用跟找到它对其他人所造成的压力，我们大家都知道，找到的机率像中头彩一样渺茫，那样做的话很自私也没效益。人活着，就有死亡，生死由命。
5. ”读圣经第几章第几节，会对你有帮助”，这种讲法是既鲁莽又失礼，再加上愚蠢与傲慢。如果Bob需要信仰帮忙的话，他自己会去找牧师，如果没有就是他不想去。这句话也会让我想拿鎚子。
6. 小心翼翼吞吞吐吐地探问是一种消极性的骚扰。让Bob一再反覆回答一些细微、无聊的蠢问题。例如「我把你吵醒了吗」，很可能Bob根本没有心情跟你作无意义的闲聊乱扯，他要么想要人们亲近他，要么跟他讲些有趣的事情（下面会讲）。
   此外，不要打电话给他然后在电话上哭，如果你感觉快要哭了，先挂断电话等个十分钟后再打。流眼泪不是问题，可是对Bob而言，「自怜」比任何其它情绪都更加灰暗。我知道该怎么主导自己的情绪，但大部分其他Bob们的心灵还是很脆弱的。

以下是Alice可以对Bob说，并且会令他感到快乐的事：

1. 曾经一起经历过的往事。”还记得那时候吗？”，”喔！我想起来了，…，真棒！”
2. 诊疗的细节。Bob现在困在病床上，他经历林林总总行礼如仪的疗程、医护人员、药物以及他罹患的疾病等等。我会立刻靠上前去倾听Bob跟我分享。
3. 帮忙Bob处理实际的问题。要让生活井然有序很复杂，需要人出手相助与心力关照。
4. 假若Bob像我一样是个作家的话，可以跟他说”我买了你的书”这一类的话，不管是基于奉承或者真心都能让Bob会心一笑。
   还有，除了快乐之外的其他情绪不必透露。记得，不要给他出新的功课。

Bob的责任

不是全部都是Alice的事，在此协定中Bob也有他的责任，至少有以下几件事：

1. 常喜乐。这点听起来有迂腐但很必要。如果Bob郁郁寡欢，Alice每次跟他讲话也会跟著心情沮丧。
2. 无庸置疑，Bob必须把自己的事情处理好。既然已经预期到来日无多，应该尽力让自己变得可有可无。在家庭上，这不可能做到，但是在工作上是做得到的。所以这几年来我已经把自己从活跃的ZeroMQ社群里面抽离了。
3. 减少所有能减少的压力跟花费。例如，比利时可以安乐死，我已经告诉医生请他们准备了（不是现在！时机到的时候…）。我会请人们当我还活著的时候来道别，不必办丧礼。如果大学觉得有用的话，我准备把器官捐给大学。
4. 认清现实。“希望”不是药，这点我已经解释过了。如果你打算跟你的医生协商，那么讨论些实用性的、让其他人都能受惠的议题。我已经告诉我的医生，如果他们想在我身上实验任何化疗药物就尽管去作。他们获得了数据，而我起码也对这个让我多活了五年以上的医疗系统作点贡献。
5. 作最坏打算。我的肿瘤医师当时一看到我的片子马上打电话给我，说她研判是癌症。左右两边的肺部都有，处处可见。我放下电话，告诉了孩子，隔天我也把最坏的状况告诉孩子们的学校，然后是家庭律师、公证人。十天之后，切片病理检验确认是癌症，这额外的十天让我有时间作准备，也让我自己有时间替自己感到悲伤。
6. 坦诚、透明地面对其他人。其他人需要有时间去悲伤，如果他们能在Bob还能讲话时跟他讨论的话，处理后事相对会简单得多。没什麼好难以啟齿的，死亡并不是失败。

   向孩子们解释

我的小孩分别是12岁、9岁、5岁。没有父亲陪著长大是一件非常不好的事情，但这是现实。但我将活在他们的DNA里面、活在Youtube上无尽的会议演讲里面，活在我的文章里面。

这几年来我已经慢慢地向他们解释很多遍：终有一天我会走，或早或晚。每个人都会死，是的，小Gregor，你也是呀。那是生命的一部分。

小Gregor，想像你有一盒乐高玩具，你拼了一栋房子，留著它又一直继续拼新的房子，旧的都不拆掉的话会发生什麼事？”盒子会变成空的，爹地”，很好，这就对了，那麼你能继续盖新房子吗？”不可以，不行了” 。嗯，我们就像乐高游戏的房子，死了以后我们会被拆解，就像回到盒子裡，让新的身体可以被生出来，这就是生死之转轮。

不过，他们最常看到的是自己的老爸快乐又轻松（不是因为止痛剂的缘故），而且好几个礼拜都感觉蛮正常地在跟他们说再见。我好感恩没有突然挂掉，我好感恩没有像植物人那样失去心智。

而且我已经告诉我的孩子们要会游泳、骑单车、溜冰跟射击，要会煮东西、要去旅行，要去露营，要会使用新的科技而不必害怕。Gregor三岁的时候就在玩Minecraft，左手键盘，右手滑鼠。Noemie七岁的时候就学会用手枪。他们会讲好几种语言。他们有自信而且学得很快，就跟他们老爸一样。

每个人都应该认识死亡的意义。构成一个完整的个体的核心之一就是接纳自己“生命有限”这个真相。当然，我们要為活下去打拼，然而当它要成為过去的时候，我们就拥抱这个终点吧。我很高兴自己能把这门功课亲自传授给孩子们，以前从来没有人会告诉我这些事情。

安乐死

我很庆幸自己最后还是没有离开比利时。这个国家允许临终或生命品质已经糟糕透顶的病人自主地选择结束生命。后者需要经过三个医师及一个精神科医师的评估，以及四个礼拜的缓冲期。若是前者则只须一个医生的评估意见。

我父亲是安乐死的，他选择了周二复活节，那时我们好几个家人陪伴他经历一个简单又安详的过程。第一剂注射让他进入昏睡状态，第二剂让心脏停止跳动。当时我觉得这样死法不错，虽然当时我不知道接著轮到我病了，（总之）安乐死是我已经想过的事。

令我感到震撼的是，都已经是2016年了依然很少国家允许安乐死，强制要求病人承受腐烂的折磨后和无效的急救，太残忍了。安乐死跟癌症特别有关系，因为癌症是主要的死因之一。如果你所属选区的民意代表反对的话，请抽空游说一下他，有尊严地死亡才是正确的方式。

我对死亡的的态度

我从来不是一个怕事的人。关于我成为掠夺者角色 （Allen Ding形容得很好的那个）这件事情，我的死亡大笔一挥让我能淡然面对它在事业与社会上所产生的风险，也让我们能够在「权力游戏 Game of Thrones」计划结束后平静下来。那从来不是真正的我，只是恰巧在那个时间、那个地点我扮演了那个必须让事情继续运作下去的角色。

我已经准备了多年去面对这一切，亲眼目睹数个精心筹划的计划同步进行的壮观场面，让我深深感到心满意足。从2011年开始我成为手枪射击专家、自学弹钢琴（还自编了几段小曲），能亲眼见到自己的小孩长成具有快乐、朝气蓬勃的性格，写了三本书，还指导ZeroMQ社群能逐步壮大。Bob如我，夫复何求？

这里的医护人员很亲切，我没有任何抱怨，我只有感恩所有的朋友，这几年来你们带给我欢乐，也感谢那些维持我性命和活力的药物。

谢谢你们 ！ :)

替孩子们着想

可以把这篇文章用在你的故事里。如果你把故事写在别的地方或想Email给我的话，可以，请复制/粘贴在本篇下方的评论(Comments)上。我想让孩子们从一个地方就可以知道他们的父亲在别人口中是怎样的人。

许多想捐点钱帮助孩子们的人在问我的Paypal帐号，它是： ph@imatix.com