A

尴尬了，中序遍历第一下，又忘了判断传入的根结点是否为空了

还是递归的，这个真不应该是中等题吧

R

这周接上周，忽然发现好像上周只读了一遍没落实下来翻译，所以金身已经各种不保，如果没有一个强力的约束的话，训练营他们一拉长了我都不想看了

还是这篇，从example一节开始

Example

Let’s take a general example at how a typical small team would collaborate using this workflow. We’ll see how two developers, John and Mary, can work on separate features and share their contributions via a centralized repository.

让我们通过一个一般化的例子看一下一个典型的小团队如果使用这个工作流（译注：接上文，说的是centralized workflow）来进行写作。我们将看到两个开发者，John和Mary如何将工作分解为特性并且共享他妈呢的哦那个先，通过一个中心化的仓库

John works on his feature

In his local repository, John can develop features using the standard Git commit process: edit, stage, and commit.

Remember that since these commands create local commits, John can repeat this process as many times as he wants without worrying about what’s going on in the central repository.

在他的本地仓库中，John能够开发特性并使用标准的git commit过程。编辑、预发和提交

计得这些命令创建了一个本地得提交，John可以重复这个过程多次而不用担心会对中心库有什么影响

Mary works on her feature

Meanwhile, Mary is working on her own feature in her own local repository using the same edit/stage/commit process. Like John, she doesn’t care what’s going on in the central repository, and she really doesn’t care what John is doing in his local repository, since all local repositories are private.

与此同时，Mary工作在她自己本地仓库上开发特性，同样使用编辑/暂存/提交流程。像John一样，她不用关心会给中心库带来什么影响，并且她真的不关心John在他自己的本地仓库里面鼓捣个啥，而且所有的本地库都是私有的

John publishes his feature

Once John finishes his feature, he should publish his local commits to the central repository so other team members can access it. He can do this with the git push command, like so:

git push origin master

Remember that origin is the remote connection to the central repository that Git created when John cloned it. The master argument tells Git to try to make the origin’s master branch look like his local master branch.

Since the central repository hasn’t been updated since John cloned it, this won’t result in any conflicts and the push will work as expectedyidan. 一旦John干完了他的活儿，他应该发布他的本地得commit到中心仓库，这样其他团队成员就可以访问它了。他可以做这件事情通过git push命令，就像这样：

git push origin master

要知道origin 是指向远程中心仓库得，它是John clone仓库时候通过git创建的。master参数告诉git 尝试让origin得master分支看着像他自己的master分支

如果中央仓库在John clone之后就没有再更新过，那么将不会有任何的冲突，推送得工作如期望的完成

Mary tries to publish her feature

Let’s see what happens if Mary tries to push her feature after John has successfully published his changes to the central repository. She can use the exact same push command:

git push origin master

But, since her local history has diverged from the central repository, Git will refuse the request with a rather verbose error message:

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.

This prevents Mary from overwriting official commits. She needs to pull John’s updates into her repository, integrate them with her local changes, and then try again.

让我们来看一下如果Mary在John成功的发布其变更到中心仓库之后尝试推送她的分支会发生什么。她可以使用完全一样得push命令：

git push origin master

但是，由于她得本地历史已经从中央仓库中发散出去，git将会拒绝这个请求并输出下面的错误信息

错误：推送失败，提是：升级被拒了因为你当前的分支落后了， 提示：远端对应物。合并了远程变更（例如，git pull） 提示：在推送之前这么做。 提示：在“git push —help”中查看“关于fast-forwards得说明”得细节

这组织了Mary 复写官方得提交，她需要把John得变更拉取到她的仓库中，集成到她自己的本地改变中，然后再次尝试

Mary rebases on top of John’s commit(s)

Mary can use git pull to incorporate upstream changes into her repository. This command is sort of like svn update—it pulls the entire upstream commit history into Mary’s local repository and tries to integrate it with her local commits:

git pull —rebase origin master

The —rebase option tells Git to move all of Mary’s commits to the tip of the master branch after synchronising it with the changes from the central repository, as shown below:

（图略）

The pull would still work if you forgot this option, but you would wind up with a superfluous “merge commit” every time someone needed to synchronize with the central repository. For this workflow, it’s always better to rebase instead of generating a merge commit.

Mary能够使用git pull 合并上游的变更到她自己的仓库中，这个命令像svn update命令，它拉去整个得上游提交历史到Mary得本地得仓库中并且尝试和她本地得commits集成在一起：

git pull —rebase origin master

这个—rebase 选项告诉Git要在和中心仓库同步后，把Mary得所有提交移到master分支得后面，就像下面这符图

如果没有这个选项，pull也能工作，但是你最终会多出个merge commit每当有人需要从中心仓库同步。在这个工作流中，永远使用rebase代替惯常得merge commit是更好的选择

Mary resolves a merge conflict

Rebasing works by transferring each local commit to the updated master branch one at a time. This means that you catch merge conflicts on a commit-by-commit basis rather than resolving all of them in one massive merge commit. This keeps your commits as focused as possible and makes for a clean project history. In turn, this makes it much easier to figure out where bugs were introduced and, if necessary, to roll back changes with minimal impact on the project.

rebase操作通过将每个本地提交在master分支上再更新一次来完成。这意味着你要在每一次提交中来处理合并冲突而不是在一个被混在一起的一大团合并操作中解决这些冲突。这保持你的提交尽可能得专注于有一个干净的工程历史。反过来，这使得找出bug更容易，如果必要的话，回退变更对项目得影响也可以最小化

If Mary and John are working on unrelated features, it’s unlikely that the rebasing process will generate conflicts. But if it does, Git will pause the rebase at the current commit and output the following message, along with some relevant instructions:

CONFLICT (content): Merge conflict in

The great thing about Git is that anyone can resolve their own merge conflicts. In our example, Mary would simply run a git status to see where the problem is. Conflicted files will appear in the Unmerged paths section:

Unmerged paths: # (use “git reset HEAD …” to unstage) # (use “git add/rm …” as appropriate to mark resolution) # # both modified:

Then, she’ll edit the file(s) to her liking. Once she’s happy with the result, she can stage the file(s) in the usual fashion and let git rebase do the rest:

git add git rebase —continue

And that’s all there is to it. Git will move on to the next commit and repeat the process for any other commits that generate conflicts.

如果Mary和John在无关的特性上各自工作，编辑操作则不大可能产生冲突。但是如果有冲突，git将会暂停rebase操作，在特定的提交上，并且输出如下有相关信息的提示

（console输出略）

Git最棒得地方是任何人都可以解决他们自己的合并冲突，在我们的例子里，Mary将简单的运行git status查看问题实什么。冲突文件将会出现在未合并路径段

（console输出略）

接着，她将编辑她喜欢的文件。一旦她对结果满意了，他就可以暂存这个文件用通常的方式并且让rebase执行接下来的工作

（命令略）

git将会移动下一个提交并重复执行任何其他的commits来解决冲突

Mary successfully publishes her feature

After she’s done synchronizing with the central repository, Mary will be able to publish her changes successfully:

git push origin master

If you get to this point and realize and you have no idea what’s going on, don’t panic. Just execute the following command and you’ll be right back to where you started:

git rebase —abort

在她我弄成和中心仓库得同步，Mry将可以成功发布她得变更（通过git push origin master命令）

如果你到了这一步并且不知道自己该干什么，不要恐慌，只需要执行git rebase —abort就可以回退到起点

Where to go from here

As you can see, it’s possible to replicate a traditional Subversion development environment using only a handful of Git commands. This is great for transitioning teams off of SVN, but it doesn’t leverage the distributed nature of Git. 就如你看到的，这就是复制了传统的Subversion 开发环境使用少量的git命令，这对于从SVN迁移到此得团队特别的棒，但是并没有利用git得分布式特性

其实有分布式不是么，都还有本地库

The Centralized Workflow is great for small teams. The conflict resolution process detailed above can form a bottleneck as your team scales in size. If your team is comfortable with the Centralized Workflow but wants to streamline its collaboration efforts, it’s definitely worth exploring the benefits of the Feature Branch Workflow. By dedicating an isolated branch to each feature, it’s possible to initiate in-depth discussions around new additions before integrating them into the official project.

中心化工作流适合小团队。冲突解决过程的细节会随着团队规模的变大而变成一个冰晶。如果你的团队在中心化工作流上工作的很舒服但是像简化合作得影响，还是值得探索一下Feature Branch工作流。每个特性会在独立的分支上，并且在合并他们到官方工程之前可以开始一个深度得讨论围绕着新的要附加的东西上

也不是到为啥，看到这里觉得有点水，剩下的下周吧

T

这周先不写吐槽吧

先写二叉树遍历这个，按说这个不是个事儿，但是今天突然一看有点懵；前序中序后序，主要是对当前节点而言，先序就是先输出自己，中序就是左子树，输出自己，然后右子树，后序就是左右子树遍历完了，再输出自己

S

为啥我的观点也像吐槽呢

这周吐一下python得 pep8，不仅工具实现上得检查力度就不足吧，比如pycodestyle就没有命名得检查，flake8倒是支持，但是还需要装一个插件pep8naming，这个真的是繁琐