月份：2017年9月

不要让 git 命令中的错误抹去你数天的工作

今天我的同事几乎失去了他在四天工作中所做的一切。由于不正确的 git 命令，他把保存在 stash[1] 中的更改删除了。在这悲伤的情节之后，我们试图寻找一种恢复他所做工作的方法，而且我们做到了！

首先警告一下：当你在实现一个大功能时，请将它分成小块并定期提交。长时间工作而不做提交并不是一个好主意。

现在我们已经搞定了那个错误，下面就演示一下怎样从 stash 中恢复误删的更改。

我用作示例的仓库中，只有一个源文件 “main.c”，如下所示：

Repository with one source file

它只有一次提交，即 “Initial commit”：

One commit

该文件的第一个版本是：

First version of the file

我将在文件中写一些代码。对于这个例子，我并不需要做什么大的改动，只需要有什么东西放进 stash 中即可，所以我们仅仅增加一行。“git diff” 的输出如下：

git-diff output

现在，假设我想从远程仓库中拉取一些新的更改，当时还不打算提交我自己的更改。于是，我决定先 stash 它，等拉取远程仓库中的更改后，再把我的更改恢复应用到主分支上。我执行下面的命令将我的更改移动到 stash 中：

git stash

使用命令 git stash list 查看 stash，在这里能看到我的更改：

Output of changes in our stash

我的代码已经在一个安全的地方，而且主分支目前是干净的（使用命令 git status 检查）。现在我只需要拉取远程仓库的更改，然后把我的更改恢复应用到主分支上，而且我也应该是这么做的。

但是我错误地执行了命令：

git stash drop

它删除了 stash，而不是执行了下面的命令：

git stash pop

这条命令会在从栈中删除 stash 之前应用它。如果我再次执行命令 git stash list，就能看到在没有从栈中将更改恢复到主分支的之前，我就删除了它。OMG！接下来怎么办？

好消息是：git 并没有删除包含了我的更改的对象，它只是移除了对它的引用。为了证明这一点，我使用命令 git fsck，它会验证数据库中对象的连接和有效性。这是我对该仓库执行了 git fsck 之后的输出：

Output after executing the git-fsck command on the repository

由于使用了参数 –unreachable，我让 git-fsck 显示出所有不可访问的对象。正如你看到的，它显示并没有不可访问的对象。而当我从 stash 中删除了我的更改之后，再次执行相同的指令，得到了一个不一样的输出：

Output after dropping changes on stash

现在有三个不可访问对象。那么哪一个才是我的更改呢？实际上，我不知道。我需要通过执行命令 git show 来搜索每一个对象。

Output after executing the git-show command

就是它！ID 号 95ccbd927ad4cd413ee2a28014c81454f4ede82c 对应了我的更改。现在我已经找到了丢失的更改，我可以恢复它。其中一种方法是将此 ID 取出来放进一个新的分支，或者直接提交它。如果你得到了你的更改对象的 ID 号，就可以决定以最好的方式，将更改再次恢复应用到主分支上。对于这个例子，我使用 git stash 将更改恢复到我的主分支上。

git stash apply 95ccbd927ad4cd413ee2a28014c81454f4ede82c

另外需要重点记住的是 git 会周期性地执行它的垃圾回收程序（gc），它执行之后，使用 git fsck 就不能再看到不可访问对象了。

自己搭建git服务器主要有两个目的:

• 可用来做一个团队的私有仓库，自己的服务器安全可控
• 让代码自动同步到服务器，而不是每次用ftp,比较方便

系统 centos6 国外vps

步骤：

1. 安装git

一般服务器都自带git。如果嫌版本低，可以选择卸载重装。

2. 创建用户

groupadd git
adduser git -g git

3.创建authorized_keys文件

cd /home/git
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
cd /home
chown -R git:git git

4. 客户端创建密钥并上传

ssh-keygen -t rsa -C "your_email"

该命令会产生两个文件: id_rsa对应私钥，id_rsa.pub对应公钥。

将id_rsa.pub中的内容写到服务器的authorized_keys文件中。

如果有多个客户端，那么在authorized_keys文件中，一行保存一个客户端的公钥。

5. 创建git仓库

为了方便管理，所有的git仓库都置于同一目录下，假设为/data/gitrepo ,

cd /data
mkdir gitrepo
chown git:git gitrepo

接下来，创建我们的第一个git仓库：sample.git ,
服务器上的Git仓库通常都以.git结尾

cd gitrepo
git init --bare sample.git
// 修改所属用户
chown -R git:git sample.git

6. 克隆仓库到本地

$ git clone git@your-ip:/data/gitrepo/sample.git

7.禁用shell登录

安全性考虑git用户只提供git服务，不让登录到系统。

编辑/etc/passwd文件 找到类似下面的一行：

git:x:503:503::/home/git:/bin/bash

改为

git:x:503:503::/home/git:/sbin/nologin

8. 设置自动更新钩子

设置当有客户端push过来自动更新到指定目录（站点目录）

cd /data/girepo/sample.git/hooks
cp post-receive.sample post-receive
vi post-receive
//添加以下这句到文件
git --work-tree=/data/wwwroot/your-site-dir checkout -f
//保存
:wq

（完）

【编者的话】将您的代码从您的Git仓库转移到您的容器可能是一件痛苦的工作。本文介绍了如何实现自动化部署。

有许多方法可以将您的源代码从Git 仓库部署到容器中，包括整个容器的重新部署、通过卷的即时重新部署或“git clone”方法。然而，当涉及到这一过程的自动化和持续部署时，许多开发人员可能会面临其中的复杂性，因为他们需要知道如何正确地将所有应用程序组件与所需的互连点结合起来。

尤其是在容器里，必须管理所构建的堆栈映像来处理CI/CD管道引起的额外复杂性。如果在操作系统、应用服务器堆栈或其依赖项中进行频繁的提交，那么整个容器重新部署可能不是最好的方法。

为了简化部署自动化，Jelastic准备了一种特殊专用的Git-Push-Deploy包，用于将代码交付到初步构建的容器映像中。这个包实现了许多配置，以便在您的Git应用程序源存储库中自动部署提交的更改，使其能够在最小延迟的情况下进行进一步的测试。

Git-Push-Deploy 细节

Git-Push-Deploy包可以与GitHub和GitLab存储库集成。它是为在Java、PHP、Ruby和Node.js和Python应用源代码中自动提供更新而开发的。可以应用于以下认证的模板:

• Java – Tomcat 6/7/8/9, TomEE, GlassFish 3/4, Jetty 6/8/9, WildFly 8/9/10, JBoss AS 7, Spring Boot 1.x
• PHP – Apache 2.4, NGINX 1.10
• Ruby – Apache 2.4, NGINX 1.10
• Node.js – Node.js 0.x-6.x
• Python – Apache 2.4

工作流依赖于项目中使用的编程语言：

• 对于基于Java的项目，该包将创建一个单独的环境，其中包含Maven构建节点，它将负责与远程Git存储库的交互，从而触发您的应用程序构建及其部署到应用程序服务器。
• 对于PHP / Ruby /Node.js/python应用中，该包为项目的部署直接在Web服务器的ROOT context上设置了一个管道（这里，认为 Ruby应用程序服务器提供的是一种部署模式，而不是dashboard的context，尽管实际项目位置是相同的）。

这个部署自动化包与4.9.5版本的Jelastic PaaS以及更高版本兼容。要查看和比较可用的管理平台和特定的Jelastic版本，请参考Jelastic Cloud Union目录。

库预配置

对于特定的附加安装，您需要为您的Git帐户提供一个个人的API Token。这可以使包为对应的存储源设置一个webhook，在每次更改代码并使其生效时，来初始化重新部署应用。

我们来生成一个。根据你所使用的Git VCS，GitHub或者GitLab对应以下指示进行操作。

在GitHub上生成Access Token

要为您的GitHub帐户获取您的personal access token，请访问Settings > Personal access tokens然后点 Generate new token按钮。

在打开的页面中，选定Token description，并选择repo和admin:repohook，在页面底部单击Generate token。

将生成的access token复制保存起来（因为离开这个页面之后，就不能再被查看）。

完成这一步之后，开始继续安装Git-Push-Deploy包。

在GitLab上生成Access Token

要在GitLab生成一个personal access token，进入您的帐户settings并切换到Access Tokens。

在这里，指定可选的token名称，它的到期日期（可以留空），并勾选api权限范围。

点击 Create Personal Access Token按钮。

在打开的页面中，复制并临时将您的访问令牌值存储在其他地方（因为离开本页后您将无法再次看到它）。

现在，您已经准备好继续安装Git-Push-Deploy包了。

Java项目的额外预配置

如果运行一个基于Java的项目，您需要通过在其结构中添加一个特殊的项目对象模型（POM）文件来开始与Maven构建节点进行适当的交互。
所以，创建一个pom.xml文件在项目源的根目录中，然后必须添加下面的内容：

<project>    
<modelVersion>4.0.0</modelVersion>    
<groupId>com.mycompany.app</groupId>    
<artifactId>my-app</artifactId>    
<version>1.0</version>    
<packaging>war</packaging>    
<build>        
<finalName>${project.artifactId}</finalName>   
</build> 
</project>

可选值:

• groupId -项目组(例如公司名称)。
• artifactId-项目的名称。
• version -应用版本。

其余的参数都应该保持不变。您可以在我们的示例中查看如何配置。

安装Git-Push-Deploy包

Git-Push-Deploy包是一个附加组件，因此它只能安装在一个环境的顶部。我们已经准备了两个独立的环境，分别使用Tomcat和apache-php应用程序服务器来展示不同编程语言的工作流。

如果你打算使用以前创建的环境，请注意这个包将覆盖部署到根目录的应用程序。因此，为了保持已经部署的应用程序，将其移动到用户目录。我们建议创建一个新的环境，然后进行接下来的安装：

1、单击dashboard顶部窗格中的Import按钮，在打开的URL选项卡中插入一个manifest.jps链接：

https://github.com/jelastic-jps/git-push-deploy/blob/master/manifest.jps

单击Import 继续。

2、在打开的框架中，指定关于源和目标环境的详细信息：

• Git Repo URL – HTTPS连接到你的应用程序的“repo“（或者 .git或普通视图）。您可以fork我们的示例Hello World应用程序来测试流。
• Branch – 项目分支。
• User – 输入您的Git登录帐户。
• Token –指定您之前为webhook生成创建的 access token。
• Environment name – 选择要部署应用程序的环境。
• Nodes – 应用程序服务器名（在选择环境时自动获取)。

单击“Install ”继续。

3、等一分钟让Jelastic从GitHub获取应用程序资源，配置webhook以进行接下来的部署。

安装完成后点击“Close“关闭通知框。

4、根据项目类型的不同，会有如下结果：

• 对于基于Java的基础设施，您将在dashboard中看到一个新的环境，其中包含Maven构建节点；它将在每次更新源代码时，在Web服务器上构建和部署应用程序到Root context下。

请注意，Maven可能需要花费一些时间来编译一个项目(尽管包安装本身已经完成了)，因此您需要等待几分钟才能启动它。这个操作的当前进展可以通过Maven的vcs_update 日志文件实时跟踪。

• 对于基于PHP的基础设施（以及其他受支持的语言），您的应用程序将直接部署到所选的服务器Root context上。

请注意，Ruby应用程序服务器的类似项目部分提供了关于使用的部署模式（默认情况下开发）的信息，而不是context，同时实际的应用程序位置也引用了服务器root。

要启动应用程序，请单击web服务器旁边的Open in browser。

就是这样！现在，您的应用程序的新版本在每次提交到源端时都会自动地发送到应用程序服务器。

不同服务栈的重新部署策略

下面的表列出了在接收到更新后的代码后不同应用服务器的反应。

为了消除可能的应用程序停机时间，可以使用重新启动更新策略，将其扩展到多个容器中。在这种情况下，所需的更新将按顺序应用到实例中，默认情况下延迟30秒。

通过Git上来测试自动部署

现在让我们来看看这个过程是如何工作的。对源端的代码做一些细微的调整，确保一切都是自动化的：

1、单击您的项目源中的某个项目的Edit this file，并Commit changes——例如，我们将修改HelloWorld启动页面上的文本。

2、因此，将触发适当的webhook来将所做的更改部署到您的主机环境中——请参考存储库Settings > Webhooks部分以了解详细信息。

单击此字符串后，您将看到由webhook发起的最近交付的列表，以及它们执行的结果。

3、最后一个检查，返回到您的应用程序页面并刷新（同时记住，Maven可能需要额外的一分钟来构建和部署您的基于Java的项目）。

就是这样！正如您所看到的，这些修改成功地应用了，因此这个方案按照我们预期的方式工作。

只需更新代码，按照通常的方法进行提交，所有的更改都会自动地推送到您的Jelastic环境中。不需要在进程之间切换，也不需要手动更新，从而消除人为错误，并加速应用程序的上线时间。

原文链接： https://dzone.com/articles/deploy-code-to-containers-from-git-automatically-1 （翻译：edge_dawn）