最近我比较痴迷的学习量化交易，发现年纪大了，确实不如年轻的时候学习能力强，只能拿时间去弥补了。为了完成参加007每周一篇文章的作业，今天写的一篇量化入门知识，自己试着总结下所学的一点东西吧。

什么是量化交易

量化交易是指以先进的数学模型替代人为的主观判断，利用计算机技术从庞大的历史数据中海选出能带来超额收益的多种“大概率”事件以制定策略。它极大地降低了市场波动给投资者情绪带来的影响，避免在市场极度狂热或悲观的情况下做出非理性的投资决策。

前面是我搜索到的专业解释。一般做交易我们是通过交易者的自身经验、偏好、分析判断进行投资决策，而量化交易是利用数学，统计学等工具对数据（历史行情数据、基本面分析、新闻资讯等）进行高效快速地分析，找到具备概率优势的量化策略，然后利用计算机强大的运算能力持续扩大这种优势。

好消息

上周一直在测试我们的比特币量化软件，我们暂时给它命名为————币赚。目前看收益还是相当可观的。

话说在前头

有几个朋友，跟我打听如何购买比特币，其中有的朋友我手把手教了如何操作，有些因为咨询我的时候我正好在忙就没有详细的给予支持。如何购买比特币的文章其实搜索一下能找到一大把的文章，但有些过时了，有些描述不清楚，有些没有突出重点步骤，对新人不容易上手。今天就成文写一篇如何购买人生中的第一个比特币吧。

前面我写过两篇文章，一篇是《为什么我们人人应该拥有比特币》，另外一篇是《比特币未来价格走势预测,4年后能超100万吗？》，我是因为真的信仰区块链，真的相信比特币的价值和价格会越来越高，所以希望把我的一些看法传递给朋友们，你没get到那是你的损失，兄弟我尽力了。有些真的有兴趣的朋友，已经在私聊我了解相关的知识，我跟每个人都强调：

老韭菜的忠言逆耳

不得不感叹人性的贪婪和欲望真的是不容易满足的。我曾经也是个小韭菜，也介绍了不少韭菜朋友入坑。在传统行业做理财有百分之十每年的收益就应已经高兴地不得了，在股市一天有个百分之十的收益，估计就觉得自己是股神了。但进入币圈之后不久，我发现人就会变，就会对每天币圈的各类币种每天百分之一二十以内的波动感觉沉闷，买的币不一两天翻个倍人是提不起劲头的。

币圈一天，人间一年。人性的一个缺点————喜欢攀比，这导致人内心的波动，行为的不一致。我们会想着别人为什么可以开大奔住洋房，自己却啃馒头租单间，头脑清醒地会觉得应该玩命努力奋斗，冲昏头脑的可能就做些伤天害理的勾当。在币圈，在金钱面前，人性的优点和缺点很容易呈现在我们眼前。

我们进入币圈多数是从比特币开始，在币圈本来拿着比特币，从历史的角度看每年几倍的涨幅是可以预期的，这在我们原来的世界已经是无法想象的。但是在币圈我们经常能看到某某币今天涨了几倍，又听别人说某某币是百倍币，别人收益增长了多少倍走向人生巅峰，然后我们就实在内心躁动，于是割了比特币去买别的币了，运气好的可能真能赚到更多收益，但是更多的是韭菜们的悲惨故事。韭菜们还站在道德高点开骂庄家心狠手辣没良心，故意制造消息割韭菜。但是，韭菜们，你完全是币圈新手，不懂的币圈的规则，凭什么敢道听途说就随便操作，不懂币圈的生存之道，凭什么就想要几十上百倍的收益。为什么不站在历史的基础上，回归已经积累的常识，多数人的共识，拿好比特币，而要奋不顾身去选择没有被历史检验的小币种呢。

在币圈这一年多，看着身边的朋友嫌弃比特币等主流币价格过高，而且价格波动小，总想着炒小币种图爆发，想着高抛低吸利润最大化，我自认没实力，因此操作谨慎，不敢贪心，我是抱着来币圈学习，归零的心态来学习炒币，参与区块链变革的，能赚则是福分。事实上，目前身边我介绍进来的几十个朋友，我这种自诩为”价值投资者“，主要玩主流币种赚到的钱算多的，玩小币种的朋友不少却亏的挺惨。

检查存储库

git状态

git status命令用于显示工作目录和分段区域的状态。它可以让您看到哪些更改已经暂停，哪些更改没有，哪些文件不被Git跟踪。输出的状态不会显示有关提交的项目历史记录的任何信息，为了获取提交历史纪录，您需要使用git log。

用法

git status

列出哪些文件已经暂存，哪些没有暂存和哪些未被追踪。

讨论

git status命令是一个相对简单的命令。它只是告诉您git add和git commit的命令是什么样子。状态消息还包括有关暂存/非暂存文件的相关说明。如下所示，显示了git status的三个主要类别的输出示例：

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
    modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
    modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
    hello.pyc

忽略文件

未被跟踪的文件通常分为两类。他们是刚刚被添加到项目和尚未提交任何文件，或他们喜欢编译的二进制文件.pyc，.obj，.exe等。git status的输出包括前者还是很有必要的，但显示后者会使得输出太多，导致您很难看到您的仓库中实际发生了什么。

因此，Git可以通过将路径放在一个特殊文件中来完全忽略文件.gitignore。您想要忽略的任何文件应该包含在单独的行中，符号可以用作通配符。例如，将以下内容添加到项目根目录中的.gitignore文件。将阻止编译的Python模块出现在git status输出中：

*.pyc

示例

在提交更改之前检查仓库的状态是很好的做法，以便您不会意外地提交您不想要的内容。此示例显示在暂存和提交快照之前和之后的仓库状态：

# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)

第一个状态输出将显示文件为未被暂存。git add操作将对第二个git status的输出产生影响
，最终状态输出将告诉您没有任何提交 - 工作目录匹配最近的提交。一些Git命令（例如，git merge ）要求工作目录是干净的，这样您就不会意外覆盖更改。

git日志

git log命令显示已提交的快照。它允许您列出项目历史记录，过滤它并搜索特定的更改。git status
允许您检查工作目录和暂存区域时，git log只对提交的的历史记录进行操作。

日志输出可以通过几种方式进行自定义，从简单的过滤提交到以完全用户定义的格式显示。一些最常见的git log配置如下所示。

用法

git log

使用默认格式显示整个提交历史记录。如果输出占用多个屏幕，则可以按下Space滚动，按下q退出。

git log -n <limit>

限制提交的数量。例如，git log -n 3只显示3个提交。

git log --oneline

冷凝每个提交到一行。这对于获得项目历史记录的高级概述很有用。

git log --stat

除了普通信息git log外，还包括哪些文件被更改，以及从每个文件中添加或删除的行的相对数量。

git log -p

显示代表每个提交的补丁。这显示了每个提交的完全差异，这是您可以拥有项目历史记录的最详细的视图。

git log --author="<pattern>"

搜索特定作者的提交。所述参数可以是纯字符串或正则表达式。

git log --grep="<pattern>"

搜索与提交消息匹配的提交，可以是纯字符串或正则表达式。

git log <since>..<until>

仅显示和之间发生的提交。这两个参数可以是提交ID，分支名称HEAD
，或任何其他类型的修订引用。

git log <file>

只显示包含指定文件的提交历史。这是查看特定文件的历史的简单方法。

git log --graph --decorate --oneline

一些有用的选择要考虑。将在提交消息的左侧绘制提交文本的图形的–graph标志。–decorate添加了显示的提交的分支或标签的名称。–oneline在单行显示提交信息，使您更容易浏览提交。

讨论

git log命令是Git浏览存储库历史记录的基本工具。当您需要查找项目的特定版本时，可以使用它；或者在功能分支中合并来后确认发生了哪些更改，可以使用它。

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

大多数是非常简单的; 然而，第一行需要一些解释。40个字符的字符串commit是提交内容的SHA-1校验。这有两个目的。首先，它确保提交的完整性 - 如果它被破坏，则提交将生成不同的校验和。第二，它作为提交的唯一ID。

该ID可以用于git log ..指向特定提交的命令。例如，git log 3157e..5ab91
将显示ID 3157e和5ab91提交之间的所有内容。除了校验和之外，分支名称（在分支模块中讨论）和HEAD关键字是引用单个提交的其他常用方法。HEAD总是指当前的提交，无论是分支还是特定提交。

〜字符用于对提交的父项进行相对引用。例如，3157e~1指的是之前的commit 3157e，而且HEAD~3是当前commit的grand-grandparent。

所有这些识别方法背后的想法是让您根据特定的提交执行操作。该git log命令通常是这些交互的起点，因为它可以让您找到要使用的提交。

示例

用法部分提供了许多git log示例，但请记住，可以将多个选项组合到单个命令中：

git log --author="John Smith" -p hello.py

这将显示John Smith对hello.py文件所做的所有更改的完整差异。

..语法是比较分支的非常有用的工具。下一个示例显示了所有在some-feature但不在master的提交的概要。

git log --oneline master..some-feature

撤消更改

本教程提供了操作软件项目版本管理所需的所有必要技能。首先，这篇文章会告诉我们如何查看旧的提交，然后解释在项目历史记录中还原公共提交与重置本地计算机上未发布的更改之间的区别。

git checkout

git checkout命令提供三个不同的功能：检出文件，检出提交和检出分支。在这篇文章中，我们只关心前两个配置。

检出提交将使整个工作目录匹配该提交。这可以用来查看您的项目的旧状态，而无需以任何方式更改您当前的状态。检出一个文件可以看到该特定文件的旧版本，使其余的工作目录保持不变。

用法

git checkout master

检出主分支。分支将在下一篇中进行深入研究，但现在您可以将其视为恢复项目“当前”状态的一种方式。

git checkout <commit> <file>

Check out a previous version of a file. This turns the that resides in the working directory into an exact copy of the one from and adds it to the staging area.

检出一个文件的以前的版本。这将工作目录中转换成一个提交时的该文件的精确副本，并将其添加到暂存区。

git checkout <commit>

更新工作目录中的所有文件以匹配指定的提交。您可以使用提交的哈希值或标标签作为参数。这将使您处于分离的HEAD状态。

讨论

任何版本控制系统背后的整个目的是“安全”存储项目的副本，以便您无需担心破坏您的代码库。一旦建立了项目历史记录，git checkout就可以将这些保存的快照“加载”到开发机器上。

检出旧的提交是一个只读操作。查看旧修订版时不可能损害您的存储库。您的在master
分支中项目的“当前”状态保持不变（有关详细信息，请参阅分支模块）。在正常的开发过程中，HEAD
通常指向主或其他本地分支，但是当您检出以前的提交时，HEAD可能不再指向分支，它会直接指向提交。这被称为“分离HEAD”状态，它可以被看成如下：

On the other hand, checking out an old file does affect the current state of your repository. You can re-commit the old version in a new snapshot as you would any other file. So, in effect, this usage of git checkout serves as a way to revert back to an old version of an individual file.

另一方面，检出一个旧文件确实会影响您的仓库的当前状态。您可以像任何其他文件一样在新快照中重新提交旧版本。所以，实际上，git checkout这种用法可以作为恢复单个文件到旧版的一种方式。

示例

查看旧版本

此示例假设您已经开始开发一个疯狂的实验，但您不确定是否要保留。为了帮助您决定，您需要在开始实验之前先了解项目的状态。首先，您需要找到要查看的修订版本的ID。

git log --oneline

假设您的项目历史记录如下所示：

b7119f2 Continue doing crazy things
872fa7e Try something crazy
a1e8fb5 Make some important changes to hello.py
435b61d Create hello.py
9773e52 Initial import

您可以使用以下git checkout方式查看“Make some important changes”的提交：

git checkout a1e8fb5

这使您的工作目录与a1e8fb5提交的确切状态相匹配。您可以查看文件，编译项目，运行测试，甚至编辑文件，而不用担心丢失项目的当前状态。您在这里做的任何事情都将保存在您的仓库中。要继续开发，您需要回到项目的“当前”状态：

git checkout master

这假设您正在开发默认的主分支，这将在《Git分支》中进行详细讨论。一旦你回到主分支，你可以使用任何一个git revert或者git reset撤消任何不需要的更改。

检出文件

如果您只对单个文件感兴趣，您也可以使用它git checkout来获取旧版本。例如，如果您只想hello.py从旧提交中查看文件，则可以使用以下命令：

git checkout a1e8fb5 hello.py

记住，与检出提交不同，这确实会影响项目的当前状态。旧文件修订版将显示为“要进行的更改（Change to be committed）”，让您有机会恢复到以前的文件版本。如果您决定不想保留旧版本，可以使用以下内容检出回最新版本：

git checkout HEAD hello.py

git还原 (git revert)

git revert命令撤销已提交的快照。但是，它不会从项目历史记录中删除提交，它会找出如何撤消引入的修改的提交，并提供追加一个新的提交来实现撤销修改的结果。这样可以防止Git丢失历史记录，这对于修订历史的完整性和可靠的协作非常重要。

用法

git revert <commit>

生成一个新的提交，撤消所有引入的更改，然后将其应用到当前分支。

讨论

当您要从项目历史记录中删除整个提交时，应使用git revert。这可能是有用的，例如，如果您正在跟踪一个错误，并发现它是由某个提交引入的。可以不用手动修改，修复它，并提交新的快照，您可以使用git revert来自动为您搞定。

还原与重置

了解git revert是如何撤消单个提交的这点很重要 - 它不会通过删除所有后续提交来“还原”回项目的先前状态。在Git中，这种做法实际上被称为重置 reset ，而不是还原（revert）。

与重置相比，还原有两个重要的优点。首先，它不会更改项目历史记录，这将使它成为已经发布到公共仓库的提交的“安全”操作。有关为什么更改公共历史记录是危险的详细信息，请参阅git reset 。

第二，git revert能够在历史上的任意位置选择某个提交，而git reset只能从当前提交中选择更早的提交。例如，如果要使用git reset撤消一个旧的提交，则必须删除目标提交之后发生的所有提交，然后将这个删除，然后重新提交这个提交后的所有后续提交。不用说，这不是一个优雅的解决方案。

示例

以下示例是一个简单的示范git revert。它提交快照，然后立即将其还原。

# Edit some tracked files
# Commit a snapshot
git commit -m "Make some changes that will be undone"
# Revert the commit we just created
git revert HEAD

这可以被视为如下所示：

请注意，第4个提交仍然在还原后的项目历史中。git revert不会删除这个提交，而是添加一个新的提交来撤消其更改。因此，第3和第5个提交代表完全相同的代码，第四个提交仍然在我们的历史，以防我们想要回滚到它。

git reset (git重置)

如果git revert是一个“安全”的方式撤消更改，你能想到的git reset就是一个危险的方法。当您使用git reset撤消（并且提交不再被任何引用或reflog引用）时，无法检索原始副本 - 它是永久撤消。使用此工具时必须小心，因为它是唯一可能失去工作的Git命令之一。

像git checkout，git reset是一个多用途的命令并许多配置项。它可以用于删除提交的快照，尽管它更常用于撤销暂存区域和工作目录中的更改。在任何一种情况下，它只能用于撤消本地更改 - 您不应该重置已与其他开发人员共享的快照。

用法

git reset <file>

从暂存区中删除指定的文件，但保持工作目录不变。这不会覆盖文件而不会覆盖任何更改。

git reset

重置暂存区以匹配最近的提交，但保持工作区不变。这不会覆盖任何更改，并让所有文件处于非暂存状态，从而让您有机会从头开始重新构建暂存快照。

git reset --hard

重置暂存区和工作目录以匹配最近的提交。包括没有暂存的更改，该–hard标志还会让Git覆盖工作目录中的所有更改。换句话说，这样会抹去所有未提交的变更，所以请确保在使用之前，确实希望废弃您的本地开发工作。

git reset <commit>

将当前分支提示向后移动，重置暂存区以匹配，但将工作区单独保留。之后所做的所有更改将放在工作区中，从而可以使用更干净，更原子的快照重新提交项目历史记录。

git reset --hard <commit>

将当前分支提示向后移动刀位置，并重置暂存区域和工作区以匹配该提交。这不仅消除了未提交的变更，也包括全部之后的提交。

讨论

所有上述方法都用于从仓库中删除更改。如果没有–hard标志，git reset是一种通过让修改和将一系列提交改为未提交的方式来清理仓库的方法。当一个实验发生可怕的错误，你需要一个完全放弃这些内容的时候使用–hard。

而还原被设计为安全地撤销公共提交，git reset旨在撤消本地更改。由于其不同的目标，两个命令的实现方式不同：重置完全删除了一系列修改，而还原维护原始的更改集，并使用一个新的提交来应用撤消。

不要在公共仓库使用git reset

绝对不要在公共仓库使用git reset。发布提交后，您必须假设其他开发人员依赖它。

删除其他团队成员持续开发的提交，对团队开发会带来严重问题。当他们尝试与您的仓库同步时，它将看起来像项目历史的一大块突然消失。下面演示了当您尝试重置公共提交时会发生什么。该origin/master
分支是您当地master分支的中央仓库版本。

一旦您在重置后添加新的提交，Git会认为您的本地历史已经脱离了origin/master，并且同步存储库所需的合并提交可能会混淆和挫败您的团队。关键是，确保您在本地实验错误的时候使用git reset ，而不是发布的更改。如果您需要撤销公共提交，那么git revert命令更合适。

示例

取消暂存文件

在准备提交暂存快照时经常使用git reset命令。下一个示例假设您有两个文件hello.py和main.py已经添加到存储库。

# Edit both hello.py and main.py
# Stage everything in the current directory
git add .
# Realize that the changes in hello.py and main.py
# should be committed in different snapshots
# Unstage main.py
git reset main.py
# Commit only hello.py
git commit -m "Make some changes to hello.py"
# Commit main.py in a separate snapshot
git add main.py
git commit -m "Edit main.py"

您可以看到，git reset通过让您将无关的更改放到下一次提交，来帮助您建立保持高度集中的提交。

删除本地提交

下一个示例显示了更高级的用例。它演示了当您在一段时间内进行新实验时会发生什么，但决定在提交几个快照后完全将其删除。

# Create a new file called `foo.py` and add some code to it
# Commit it to the project history
git add foo.py
git commit -m "Start developing a crazy feature"
# Edit `foo.py` again and change some other tracked files, too
# Commit another snapshot
git commit -a -m "Continue my crazy feature"
# Decide to scrap the feature and remove the associated commits
git reset --hard HEAD~2

git reset HEAD~2命令将当前分支向后移动两次提交，从而有效地从项目历史记录中删除刚刚创建的两个快照。请记住，这种重置应仅用于未发布的提交。如果已将您的提交推送到公共仓库，则不要执行上述操作。

git clean

git clean命令从您的工作目录中删除未追踪的文件。这真的是一个方便的命令，通过git status看看哪些文件没有跟踪和然后手动删除它们。像一个普通的rm命令，git clean是不可逆的，所以一定要确保在运行它之前你真的想要删除未跟踪文件。

git clean命令通常与git reset –hard结合执行。请记住，重置仅影响已跟踪的文件，因此需要单独的命令来清理未跟踪的文件。综合这两个命令可让您将工作目录恢复到特定提交的确切状态。

用法

git clean -n

执行git clean的“无效运行”模式。这将显示哪些文件将被删除，而不会真实执行。

git clean -f

Remove untracked files from the current directory. The -f (force) flag is required unless the clean.requireForce configuration option is set to false (it’s true by default). This will not remove untracked folders or files specified by .gitignore.

从当前目录中删除未跟踪的文件。除非clean.requireForce的配置选项设置为false（默认情况下这是true），则需要-f（强制）标记。这不会删除未跟踪的文件夹或.gitignore指定的文件.

git clean -f <path>

删除未跟踪的文件，但将操作限制到指定的路径。

git clean -df

从当前目录中删除未跟踪的文件和未跟踪的目录。

git clean -xf

从当前目录以及Git通常忽略的任何文件中删除未跟踪的文件。

讨论

The git reset –hard and git clean -f commands are your best friends after you’ve made some embarrassing developments in your local repository and want to burn the evidence. Running both of them will make your working directory match the most recent commit, giving you a clean slate to work with.

The git clean command can also be useful for cleaning up the working directory after a build. For example, it can easily remove the .o and .exe binaries generated by a C compiler. This is occasionally a necessary step before packaging a project for release. The -x option is particularly convenient for this purpose.

Keep in mind that, along with git reset, git clean is one of the only Git commands that has the potential to permanently delete commits, so be careful with it. In fact, it’s so easy to lose important additions that the Git maintainers require the -f flag for even the most basic operations. This prevents you from accidentally deleting everything with a naive git clean call.

如果你在本地库开发过程中遇到问题，并要烧掉所有证据，git reset –hard和git clean -f命令你一定很喜欢。运行它们将使您的工作目录匹配最近的提交，给您一个干净的工作。

git clean命令也可用于清理构建后的工作目录。例如，它可以很容易地除去.o和.exe由C编译器生成的二进制文件。在包装项目发布之前，这偶尔是一个必要的步骤。该-x选项对于此目的特别方便。

请记住，与之一起的git reset，git clean是唯一可以永久删除提交的Git命令之一，所以要小心。事实上，它是如此容易失去了Git的维护者重要的补充需要的-f，即使是最基本的操作标志。这样可以防止您无意中使用git clean删除所有内容。

示例

以下示例清除了工作目录中的所有更改，包括已添加的新文件。它假设您已经提交了几个快照，并正在尝试一些新的开发。

# Edit some existing files
# Add some new files
# Realize you have no idea what you're doing
# Undo changes in tracked files
git reset --hard
# Remove untracked files
git clean -df

运行此重置/清除序列后，工作目录和暂存区域将与最近的提交完全相同，并且git status将报告一个干净的工作目录。你现在准备重新开始了。
请注意，与第二个示例不同git reset ，新文件_not _added到存储库。因此，他们不会受到影响git reset –hard，git clean被要求删除它们。

介绍

版本控制系统是一类软件工具，可帮助软件团队基于时间的变化来管理源码。版本控制系统跟踪特殊类型数据库中代码的每个修改。如果发生错误，开发人员可以回到某个时间点，比较早期版本的代码，以帮助解决错误，同时最大限度地减少对所有团队成员的干扰。

对于几乎所有的软件项目，源代码就是财富 - 这个珍贵的资产必须被保护。对于大多数软件团队来说，源代码是开发者们通过认真的努力工作和宝贵知识的结晶。版本控制系统保护源代码免受灾难事故、偶尔人为错误的和意外的后果的破坏。

团队合作的软件开发人员不断编写新的源代码和更改现有的源代码。项目，应用程序或软件组件的代码通常组织在文件夹结构或“文件树”中。团队中的一名开发人员可能正在开发新功能，而另一位开发人员通过更改代码来修复无关的错误，每个开发人员可能会在文件树的多个部分进行更改。

版本控制可帮助团队解决这些问题，跟踪每个贡献者的每一个变化，并帮助防止并发工作的冲突。在软件的一部分进行的更改可能与另一位开发人员同时进行的更改不兼容。这个问题应该有序发现和解决，而不会阻止团队其他成员的工作。此外，在所有软件开发中，任何更改都可能无意引入新的错误，并且新的软件在被测试之前是不可完全相信的。所以测试和开发同时进行，直到新版本准备就绪。

良好的版本控制系统支持开发人员的喜爱的工作流程，而不强加一种特定的工作方式。理想情况下，它也适用于任何平台，而不是指定开发人员必须使用的操作系统或工具集。优秀的版本控制系统应当促进代码的流畅和持续的修改，而不是带来令人沮丧和笨拙的给文件加锁的机制 - 给一个开发人员带来绿灯，却付出阻止其他人的继续操作的代价。

不使用任何形式的版本控制的软件团队经常遇到问题，例如不知道已经为用户提供了哪些更改，或者在两个不相关的工作之间创建不兼容的更改，然后必须非常痛苦地解决问题甚至重头再来一遍。如果您是从未使用版本控制的开发人员，您可能已经添加了您的文件的版本，也许使用后缀“final”或“latest”，然后再处理新的最终版本。也许你已经注释掉了代码块，因为担心以后可能会使用它。你想禁用某些功能而不删除代码。版本控制是摆脱这些困扰的一种办法。

版本控制系统是现代软件团队专业实践的每一天的重要组成部分。习惯于在其团队中使用能力强大的版本控制系统的个人软件开发人员通常认识到版本控制的巨大价值，因此他们甚至在小型个人项目上也使用版本控制系统。一旦习惯了版本控制系统的强大优势，即使是非软件项目，许多开发人员也不会考虑工作。

版本控制系统的好处

开发软件而不使用版本控制是有风险的，就像没有备份一样。随着团队规模扩大，版本控制还可以使开发人员能够更快地开发，并允许软件团队保持效率和敏捷性。

版本控制系统（VCS）在过去几十年中取得了很大的进步，一些比其他控制系统更好。VCS有时被称为SCM（源代码管理）工具或RCS（版本控制系统）。今天使用的最流行的VCS工具之一就是Git。Git是一个分布式 版本控制系统。像许多目前最流行的VCS系统一样，Git是免费的和开源的。不管它们被称为什么，或使用哪种系统，您应该期望从版本控制的主要好处如下：

1. 每个文件的完整的修改历史。这意味记录每个人的每一个修改，这些修改包括文件的创建和删除以及对其内容的编辑。不同的VCS工具在处理文件的重命名和移动方面有所不同。这个历史还应包括作者的日期和修改说明，以便每次更改的目的。具有完整的历史记录可以回溯到以前的版本，以帮助根本原因分析错误，并且在需要修复旧版软件的问题时至关重要。如果软件正在积极地工作，几乎所有的东西都可以被认为是软件的“旧版本”。

2. 分支和合并。团队成员同时开发一个文件是不太好，但是即使个人也可以从独立的开发流中获益。在VCS工具中创建“分支”可以使多个工作流彼此独立，同时还提供将该工作合并到一起的功能，使开发人员能够验证每个分支上的更改是否都不会发生冲突。许多软件团队采用针对每个功能进行分支的做法，或者针对每个版本或两者都采用分支。当他们决定如何利用VCS中的分支和合并工具时，团队有许多不同的工作流可以选择。

3. 可追溯性。能够跟踪对软件的每个更改，并将其连接到项目管理和错误跟踪软件（如JIRA），并且能够通过描述更改目的的消息来注释每个更改，可以帮助根本上分析问题原因和其他取证。当您阅读代码时，将代码的注释历史记录在您的电脑，可以使开发人员尝试了解它正在做什么以及为什么这样设计，并能够据此进行正确合理的开发工作。这对于遗留代码尤其重要，并且对开发人员能够准确性估计未来工作至关重要。

总结

虽然在不使用任何版本控制系统的情况下也可以开发软件，但这样做会使项目面临巨大的风险，建议专业团队必须使用版本控制系统。所以问题不在于是否使用版本控制（因为必须使用），而是使用哪个版本控制系统。

版本控制系统有很多选择，但是在这里我们将专注于一个，Git。

原文出处

What is version control

git add

git add命令将工作目录中的更改添加到暂存区。它告诉Git你想在下一个提交中包含特定文件的更新。但是，git add并不会以任何重大的方式影响仓库 - 在运行git commit 之前，实际上并不会记录更改。

这些命令，您还结合需要git status命令查看工作目录和暂存区的状态。

用法

git add <file> 

为下一次提交暂存下的所有修改。

git add <directory>

对下一次提交暂存目录下的所有更改。

git add -p

开始交互式登台会话，让您选择要添加需要暂存到下一个提交的文件哪些部分。这将提供一系列修改块，并提示您进行命令。使用y暂存这个修改块，使用n来忽略该块，使用s将其拆分成较小的块，e手动编辑该块，然后q退出。

讨论

命令git add和git commit命令组成了基本的Git工作流程。这些是每个Git用户需要了解的两个命令，不管他们的团队合作模式如何。它们是将项目的版本记录到仓库历史记录中的方法。

开发项目基本围绕编辑/暂存/提交模式。首先，在工作目录中编辑文件。当您准备保存项目当前状态的副本时，您可以使用git add暂存更改。在您对暂存的快照感到满意之后，您就可以使用git commit将其提交到项目历史记录中。

git add命令不应该被混淆svn add，svn add将文件添加到仓库。相反，git add在修改的更抽象的层面上工作。这意味着git add每次更改文件时都需要调用，而svn add只需要为每个文件调用一次。这可能听起来是冗余的，但是这个工作流使得项目的组织变得更加容易。

暂存区

暂存区是Git更独特的功能之一，如果您有来自SVN（甚至Mercurial）背景，可能需要一些时间才能将其理解。可以将其视为工作目录和项目历史记录之间的缓冲区。

不提交自上次提交以来所做的所有更改，您可以在提交到项目历史记录之前，选择相关的更改暂存到高度聚焦的快照中。这意味着您可以对不相关的文件进行各种编辑，然后返回并将其分解为逻辑提交，再将相关更改添加到暂存区中并逐个提交。与任何版本控制系统一样，重要的是创建原子提交，以便轻松地跟踪错误并恢复更改，同时对项目的其余部分影响最小。

示例

当您开始一个新项目时，git add具有与svn import相同的功能。要创建当前目录的初始提交，请使用以下两个命令：

git add .
git commit

一旦你的项目运行正常，可以通过将路径传递给git add：

git add hello.py
git commit

上述命令也可用于记录对现有文件的更改。再次强调，Git并不区分新文件中的暂存更改与已经添加到仓库的文件的更改。

git提交

git commit命令将暂存的快照提交到项目历史记录。提交的快照可以被认为是项目的“安全”版本 - 除非你明确地要求，否则Git永远不会改变它们。结合git add，这是最重要的Git命令之一。
虽然他们共享相同的名字，但这个命令并不是什么svn commit。快照将致力于本地仓库，并且这绝对不需要与其他Git仓库进行交互。

用法

git commit

提交暂存快照。这将启动一个文本编辑器，提示您提交提交消息。输入消息后，保存文件并关闭编辑器以创建实际提交。

git commit -m "<message>"

提交暂存快照，而不是启动文本编辑器，用作提交消息。

git commit -a

提交工作目录中所有更改的快照。这仅包括对跟踪文件的修改（git add在历史记录中的某个时刻添加的文件）。

讨论

快照一直是在本地仓库。这与SVN基本不同，其中工作副本被提交到中央仓库。相比之下，Git不会强制您在准备好之前与中央仓库进行交互。正如暂存区是工作目录和项目历史记录之间的缓冲区一样，每个开发人员的本地仓库都是它们的贡献和中央仓库之间的缓冲区。

这改变了Git用户的基本开发模式。Git开发者不用改变，直接将其直接交给中央仓库，而是有机会在本地仓库中累积提交。与SVN风格的协作相比，它具有许多优点：它可以将功能分解为原子提交，将相关的提交分组在一起，并在发布到中央仓库之前清理本地历史记录。它还使开发人员在孤立的环境中工作，推迟合并，直到它们处于方便的时候。

快照，而不是差异

除了SVN和Git之间的实际区别之外，它们的基本实现也遵循完全不同的设计理念。而SVN跟踪文件的差异，Git的版本控制模型基于快照。例如，SVN提交包含与添加到仓库的原始文件相比较的diff。另一方面，Git 在每个提交中记录每个文件的全部内容。

这使得许多Git操作比SVN快得多，因为特定版本的文件不需要从其diffs“组装” - 每个文件的完整版本可以立即从Git的内部数据库获得。

Git的快照模型对其版本控制模型的几乎每个方面都有深远的影响，影响了从分支和合并工具到协作工作流程的所有内容。

示例

以下示例假设您已在一个文件中编辑了一些内容，hello.py并准备将其提交给项目历史记录。首先，您需要对文件进行git add暂存，然后可以提交暂存快照。

git add hello.py
git commit

这将打开一个文本编辑器（可自定义通过git config）请求提交消息，以及正在提交的内容的列表：

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py

Git不需要提交消息来遵循任何特定的格式化约束，但是规范格式是以不超过50个字符的方式总结第一行上的整个提交，留下空行，然后详细说明已更改的内容。例如：

Change the message displayed by hello.py
- Update the sayHello() function to output the user's name
- Change the sayGoodbye() function to a friendlier message

请注意，许多开发人员也喜欢在其提交消息中使用现在时态。这使得它们更像是在仓库中的操作，这使得许多历史重写操作更加直观。

我们将SVN迁移到Git的步骤拆解成5个简单的步骤：

1. 准备迁移的环境。
2. 将SVN仓库转换成本地Git仓库。
3. 当SVN仓库发生变化时同步到本地Git仓库。
4. 通过Git服务器共享你的Git仓库给其他开发者。
5. 将你的开发工作从SVN迁移到Git仓库里。

准备、转变、同步步骤需要一个SVN提交历史并将它转至Git仓库。操作这三部的最好方式是指定一个人做为迁移负责人（如果你读了这篇文章可能就是你了）。所有这三步应当在迁移负责人的本地电脑上执行。

在同步阶段完成后，迁移负责人可以很轻易的保持本地Git仓库和SVN仓库同步更新，为了共享他的Git仓库，迁移负责人需要将他的本地Git仓库推送到一个Git宿主服务器，比如Gitlab、GitHub、Bitbucket等。

如果服务器是在Bitbucket上，其他开发者可以克隆Git仓库将代码转移至本地，使用Git命令查看历史，将该服务器用于构建代码流程中。然而我们提倡，在你们团队准备好一个纯净的Git工作流的时候，采取一步到位的方式来迁移SVN到Git。这意味着团队每个人对这个服务器是只读的，他们依旧将代码提交到SVN仓库。将这些修改的操作应当交给迁移负责人来同步、推送这些修改到Bitbucket。

这让你团队在明确切换这段时间内可以熟悉Git开发工作流，而不用中断基于SVN的工作流。一旦你确信所有开发者已经准备好切换到Git，那最后的一步就是冻结你的SVN仓库，让大家开始使用Git提交代码。

这个切换应该是一个非常自然的过程。整个Git工作流已经开始运转，并且开发者有大把的时间去熟悉它。从这刻起，你已经成功地将你的项目从SVN迁移到Git上了。

原文出处

Migrate to Git from SVN

在《为什么选择Git?》文章里，我们探讨了如何使用Git来帮助我们团队开发更敏捷，一旦你决定做转变到使用Git，你下一步就是找出如何将你现在工作流迁移到Git上的方法。

这篇文章将会介绍在你从SVN迁到Git上会遇到的一些最大的变化。在迁移过程中你需要记住一件很重要的事情就是Git和SVN是不同的。意识到Git的巨大潜力，努力脑洞大开去从一些的新的角度去考虑版本控制。

从管理员的角度

根据团队的规模的不同，使用Git需要使用几天到几个月不等的时间。这个章节我们来阐述在培训工程师使用Git和迁移仓库到Git时，工程管理者主要关心的问题。

Git基本命令

Git被大家认为门槛其实挺高的。不过Git的维护者已经逐步地发布了一些改进版本，比如实用的默认配置以及上下文帮助信息，这些措施让我们的学习过程更加轻松愉快。

Atlassian提供了综合的自我学习系列课程Git教程，也提供了论坛和在线培训课堂。这些可以让我们的团队学习Git提供了选择。下面列出一些常见的Git基础命令来帮助你开始熟悉Git：

Git迁移工具

有很多工具可以帮助我们迁移SVN代码到Git。但在我们选择工具前，我们先确认你想如何迁移你的代码，你的选择有如下四个：

• 迁移你的整个代码库到Git并且一起放弃使用SVN。

• 不迁移已经存在的项目到Git，但是所有新项目使用Git.

• 迁移部分项目到Git，然而其他项目使用SVN。

• 在同一项目同时使用SVN和Git.

完全的迁移到Git会降低你开发工作流的复杂度，因此这是一个更好的选择。但是，在成百上千的大型团队里，包含几百项目这通常不太可能。在这种情况下，混合策略是一个更安全的做法。

迁移工具的选择很大程度取决于你选择哪个策略。下文我们介绍一些常见的SVN到Git的迁移工具。

Atlassian公司的迁移脚本

如果你对快速迁移Git感兴趣，Atlassian公司的迁移脚本是一个好的选择。这些脚本提供所有你需要的工具，它们可以妥妥的将你的SVN仓库迁移到Git仓库。在迁移之后你将不需要处理SVN-to-Git的互相影响的问题。

我们提供了一个完整的《技术演练教程》,介绍如何使用这些脚本来将你整个代码库转变为一个Git仓库集。这个演练教程解释了所有关于提取SVN信息到重构不标准的SVN仓库结构的知识。

SVN Mirror for Stash (now Bitbucket Server) plugin

SVN Mirror for Stash 是Bitbucket Server 插件，让你可以很容易的维护一个同时使用SVN和Git的混合代码库。和Atlassian公司的迁移脚本不同，SVN Mirror for Stash可以让你一直在同一仓库同时使用SVN和Git.

对于大型公司这个拖鞋方案是一个最好的选择。通过让不同团队在他们的方便的时候再做迁移，它能够采用增量Git。

Git提交到SVN服务器

Git的git svn工具可以作为本地Git仓库和远程SVN仓库的接口，它让开发者可以在本地写代码然后使用Git创建本地提交，然后使用svn提交方式来推送代码到中央SVN仓库。

如果你还没有确定要切换到Git并且希望有工程师可以研究一下Git命令，这时候git svn是一个好的选择。它也是很适合培训阶段，而不是突然转变的过程，你的团队可以可以很轻松地在本地使用Git命令，而不必担心团队合作工作流。

git svn仅仅应该作为你迁移过程中的临时阶段。因为它仍然使用SVN作为后端，因此不能充分发挥Git功能的强大，比如分支或者高级合作开发流。

部署策略

迁移代码只是采用Git的一个方面。你也需要考虑培训写代码的人。在迁移你的团队到Git上，采用外部专家培训、内部培养Git高手、先锋队是三个主要的策略。

外部Git专家

Git专家能够用合适的价格为你处理这个迁移过程。这个优势也很明显，你不用去花费时间去调研适合你团队的工作流，就可以建立适合你团队的最佳工作流。而且让你的团队可以得到学习Git的资源。Atlassian Experts是一个很好的资源，当你从SVN迁移到Git时这个非常有用。

并且，由你自己去设计和实施Git工作流，可以让你的团队理解新的工作流的内部工作原理。这避免了专家离开的后的空白所带来的风险。

内部Git高手

Git高手是你公司对Git很有热情的开发者，对于有工程师文化和强烈学习意愿的开发者发挥Git高手的价值更有用。这可以让你的一个工程师可以成为Git专家，因此他们可以设计一个Git工作流服务于公司，当团队其他人需要迁移到Git的时候这个人可以作为专家顾问的角色提供帮助。

相比外部专家，这可以让你的团队有一个Git高手，然而，它可能需要更多的时间去培训那个Git高手。而且可能会选错工作流或者实施不到位的风险。

先锋队

迁移到Git第三个选择就是可以在先锋队中试验。如果有个小团队在一个相对独立的项目中工作使用这个方法最佳。结合外部顾问专家和内部先锋队的Git高手在一起这样能取得更好的效果。

相比外部购买的的方案这有优势也有可能选错工作流的风险，因为它是由整个团队来设计开发过程。不过，相比让顾问专家或者专家完全自己来设计新的开发工作流，它确保团队不错过任何细节。

而且，使用先锋队的方式因为更多的基础培训和建立时间：由于不是一个开发者去发现新的开发工作流，而是整个团队潜在可能降低效率，因为团队可能习惯新的工作流需要时间。然后，短时间的付出相比长期的回报来说还是值得的。

安全和权限

在你需要重新考虑如何在Git中管理代码的时候访问权限控制是一个方面。

在SVN中，我们通常将所有代码保存在一个单一的中央仓库，然后通过文件夹给不同团队或者个人限制访问权限。在Git中，这不可能：开发者必须取出整个仓库来从事开发，通常不能只活去仓库的一部分代码，而在SVN中是可的。权限授权是针对整个Git仓库进行的。

这意味着你必须拆分你巨大的SVN仓库为几个不同的Git仓库。当我们将JIRA开发团队迁移到Git时，我们事实上在Atlassian经历过一次这样的情况。我们所有的JIRA插件都是存储在一个单一的SVN仓库，但是在迁移之后，我们为每个插件建立了一个仓库。

Git当初设计的时候是为了保证安全的合并成千上万的Linux开发者的代码，这点我们要时刻记住。因此它当然有一些方法来设置任何你团队需要的访问权限。当然，这需要对构建周期有一个全新的视角。

如果你关心保持你新仓库集的依赖，你可能发现在Git上面的一个依赖管理层非常有用。在仓库不断增大，依赖管理层将通过构建次数来提供帮助，为了加快构建时间，你需要“缓存”。这篇文章：“Git and project dependencies”，列举了为每个技术栈推荐的依赖管理层工具。

从开发者的角度

所有开发者的一个仓库

作为开发，你需要适应和理解Git分布式的特性，相比一个单一的中央仓库，每一个开发者本地有整个仓库的备份，这极大的改变了你和同事们的合作方式。

我们使用svn checkout命令来检出一个SVN仓库的代码，然后在Git中你通过git clone来克隆整个Git仓库到电脑上。

合作开发经常会使用git push ,git pull或者git fetch命令在git仓库之间切换分支。在Git中经常使用在分支层面共享代码，当然也可以像SVN一样通过提交来实现。但在是在Git中，一个提交代表整个项目的状态而不是一个文件的修改。一旦你在Git和SVN中能够使用分支，他们最大的区别就是你可以使用Git提交到本地，而不用把代码提交到服务端。这可以让你更自由的实验，离线状态下更有效率的工作，几乎所有的命令操作起来更快。

但是，要清楚的知道远程仓库不实直接和你的仓库关联的，它仅仅是一个书签，可以避免在你需要和远程仓库交互的时候你必须频繁输入完整的URL链接。直到你明确的拉取或者推送分支到远程仓库，你一直在自己独立的环境下工作。

对于SVN使用者来说另一个很大转变就是意识到本地和远程仓库的概念。本地仓库存在于你自己的电脑上，其他的仓库都是远程仓库。远程仓库存在的主要目的就是让你的代码可以共享给其他成员。因此在远程仓库并不会有进行中的开发。你电脑上的本地仓库则你所有软件开发的场所。

无惧分支和合并

SVN中，我们在工作区编辑文件然后提交，然后执行svn commit来推送代码到中央仓库。每个人可以通过svn update拉取这些修改到他们的工作区。SVN分支在大型，长时间维护的项目中不怎么使用，因为合并非常的危险，可能会破坏项目。

Git的基本开发工作流则不同，分支和合并非常的容易，而不是只能一条线的开发（比如trunk/）。

当你想在Git中开始工作，你可以使用git checkout -b 来检出一个新的分支，这可以让你有一个专门的开发线，而不用担心会影响其他人。如果你对项目产生了破坏，而且没办法修复，你完全可以使用git branch -d 丢弃这个分支。如果你开发了一些有用的功能，你可以发起一个合并申请来合并你的代码到master分支。

常见的开发工作流

在选择开发工作流的时候最好考虑团队的需要。一个简单的工作流可以加快开发速度和提高灵活性，然而一个复杂的工作流可以确保更好的一致性和对开发工作的掌控。你可以结合下面介绍的常见的方法来适应你的需要以及团队的不同角色的需要，比如，一个核心的开发者可以使用功能分支而一个外包人员可以在分叉（fork）上开发。

集中式开发工作流提供类似SVN的工作流程，因此对于开始使用Git来说非常合适。

为开发一个功能需求，使用分支开发工作流 再合适不过了，它绕过开发者的工作保持独立，而且重要的是保护公共分支。功能分支也构成了让我们能够使合并申请来管理修改的基础。

Git流开发工作流 是一个更加正式而且是对功能分支的结构性的扩展，是大团队的一个很好的选择，因为它明确定义了产品发布的周期。

最后，如果你需要最大限度的保持仓库隔离，控制代码修改，或者有许多的开发者在为仓库贡献代码，这时候你可以考虑使用分叉（forking）开发工作流 。

作为一个专业团队。如果你真的想发挥Git的最大价值，你应当考虑使用分支开发工作流，它是真正的分布式开发工作流，保证了高度的安全性，极大的可扩展性，非常必要的灵活性。

总结

让你的团队过渡到Git不是一件容易的事情，不过也没多难。这篇文章介绍了迁移你的代码库的常见选项，向开发团队推荐Git,处理安全和权限问题。这篇文章也介绍了在迁移过程中开发者们寻药准备好接受的一些挑战。

最后希望你已经掌握强有力的知识基础，来将Git分布式开发工作流介绍到你们公司，而且不管团队的大小或者当前你们是什么开发流，都可以迁移。

原文出处

SVN to Git - prepping for the migration