运行你自己的服务器将有许多权限且允许你运行该服务于你自己的防火墙内，但如此通常需要耗费你大量的时间 去设置与维护服务器。 如果你放置你的资料于托管服务器内，可轻易的设置与维护；无论如何，你必须能够保 存你的代码在其他服务器，且某些组织不允许此作法。 这将直截了当的决定哪个作法或组合的方式较适合你或 你的组织。 123 分布式 Git 你现在拥有了一个远程 Git 版本库，能为所有开发者共 这很重要，因为随着开发者越来越多，在确保你的代码能干净地应用或轻松地合并时会遇到更多问题。 提交的 改动可能表现为过时的，也可能在你正在做改动或者等待改动被批准应用时被合并入的工作严重损坏。 如何保 证代码始终是最新的，并且提交始终是有效的？ 下一个影响因素是项目使用的工作流程。 它是中心化的吗，即每一个开发者都对主线代码有相同的写入权限？ 项目是否有一个检查所有补丁的维护者或整合者？ 是否所有的补丁是同行评审后批准的？ --tags 选项。 你也可以使用这个字符串来调用 git checkout 或 git show 命令， 但是这依赖于其末尾的简短 SHA-1 值，因此不一定一直有效。 比如，最近 Linux 内核为了保 证 SHA-1 值对象的唯一性，将其位数由 8 位扩展到了 10 位， 导致以前的 git describe 输出全部失效。 准备一次发布 现在你可以发布一个构建了。 其中一件事情就是为那些不使用

#查看全局设置 ★本地设置 针 对 单 一 项 目 的 设 置 ， 使 用 --local 参 数 ， 本 地 设 置 信 息 保 存 在 项 目 目 录/.git/config文件里 # cd 项目目录 # git init #初始化仓库，将在当前路径下生成.git子目录，子目录里有

在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么 （463dc4f），以及在本次提交中，有多少文件修订过，多少行添加和删改 过。 请记住，提交时记录的是放在暂存区域的快照。 任何还未暂存文件的仍然保 持已修改状态，可以在下次提交时纳入版本管理。 每一次运行提交操作，都 是对你项目作一次快照，以后可以回到这个状态，或者进行比较。 跳过使用暂存区域 尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁 最终你的提交历史看起来像下 面这个样子： 图表 29. 合并了 dumbidea 和 iss91v2 分支之后的提交历史 我们将会在 分布式 Git 中向你揭示更多有关分支工作流的细节， 因此，请确 保你阅读完那个章节之后，再来决定你的下个项目要使用什么样的分支策略 （branching scheme）。 请牢记，当你做这么多操作的时候，这些分支全部都存于本地。 当你新建和 合并分支的时候，所有这一切都只发生在你本地的 默认情况下它会在 终端中提示服务器是否允许你进行推送。 如果不想在每一次推送时都输入用户名与密码，你可以设置一个 “credential cache”。 最简 单 的 方 式 就 是 将 其 保 存 在 内 存 中 几 分 钟 ， 可 以 简 单 地 运 行 git config --global credential.helper cache 来设置它。 想要了解更多关于不同验证缓存的可用选项，查看

Files ( ui.csv ) Markdown ( markdown ) 服务器 ( server ) 配置说明 - 92 - 本文档使用 书栈网 · BookStack.CN 构建 保 $STATIC_URL_PREFIX/assets/css/index.css 指向 /var/www/assets/css/index.css 。 HTTP_ADDR : 0.0.0.0：HTTP