宕机怎样 规复 正常（宕机重启）〔宕机怎么处理〕

　　泉源 ：伯乐在线专栏作者 - SamLau

　　如有好的文章投稿，请点击 → 这里查察 详情

　　Git Version Control

　　这篇文章是针对git版本控制和工作流的总结 ，假如 有些朋侪 之前还没利用 过git，对git的根本 概念和下令 不是很认识 ，可以从以下根本 教程入手：

专为计划 师而写的GitHub快速入门教程

git – 简明指南

学习Git的在线互动教程

　　根本 概念

　　Git是什么？

　　Git是分布式版本控制体系 ，与SVN雷同 的会合 化版本控制体系 相比，会合 化版本控制体系 固然 可以或许 令多个团队成员一起协作开辟 ，但偶然 假如 中心 服务器宕机的话 ，谁也无法在宕机期间提交更新和协同开辟 。乃至 偶然 ，中心 服务器磁盘故障，碰巧 又没有做备份或备份没及时 ，那就大概 有丢失数据的风险。

　　但Git是分布式的版本控制体系 ，客户端不但 是提取最新版本的快照，而且将整个代码堆栈 镜像复制下来 。假如 任何协同工作用的服务器发生故障了 ，也可以用任何一个代码堆栈 来规复 。而且在协作服务器宕机期间，你也可以提交代 码到本地 堆栈 ，当协作服务器正常工作后，你再将本地 堆栈 同步到长途 堆栈 。

　　为什么要利用 Git

可以或许 对文件版本控制和多人协作开辟

拥有强大 的分支特性 ，以是 可以或许 机动 地以差别 的工作流协同开辟

分布式版本控制体系 ，纵然 协作服务器宕机，也能继承 提交代 码或文件到本地 堆栈 ，当协作服务器规复 正常工作时，再将本地 堆栈 同步到长途 堆栈 。

当团队中某个成员完成某个功能时，通过pull request操纵 来关照 其他团队成员 ，其他团队成员可以或许 review code后再归并 代码。

　　Git有哪些特性

文件三种状态(modified, staged, committed)

直接记录 快照，而非差别 比力

多数操纵 仅添加操纵

近乎全部 操纵 都是本地 实行

时候 保持数据完备 性

　　有关以上特性的具体 表明 ，请查察 Pro git的git底子 章节

　　Git根本 工作流程

在git版本控制的目次 下修改某个文件

利用 git add下令 对修改后的文件快照 ，生存 到暂存地区

利用 git commit下令 提交更新，将生存 在暂存地区 的文件快照永世 转储到 Git 目次 中

　　Git根本 本领

主动 补全

Git 下令 别名

　　关于具体 怎样 利用 主动 补全和定名 别名本领 ，请查察 Pro git的本领 和秘诀

　　Git版本控制

　　创建堆栈

git init

git clone

git config

　　生存 修改

　　git add

　　git commit

　　查察 堆栈

git status

git log –oneline

　　取消 修改

　　查察 之前的commit

git checkout commit file

git checkout commit

git checkout branch

　　取消 公共修改

git revert commit

　　取消 本地 修改

git reset

git clean

　　重写Git汗青 记录

git commit –amend

git rebase

git reflog

　　Git协作开辟

　　分支

git branch

git checkout

git merge

　　堆栈 同步

git remote

git fetch

git pull

git push

　　Git工作流

　　由于git拥有强大 的分支特性 ，它的工作流比力 机动 而缺乏束缚 ，于是参考Atlassian Git Tutorial的Comparing Workflows章节提供四种Git工作流：

Centralized Workflow

Feature Branch Workflow

Gitflow Workflow

Forking Workflow

　　以上工作流只是参考指南，而不是具体 规则。你可以根据本身 实际 环境 来选择得当 本身 的工作流或微调来满意 本身 的必要 。

　　Centralized Workflow

　　过渡到分布式版本控制体系 看起来像一个困难 的任务 ，但假如 你充实 利用 好git的话 ，你不必改变你既有的工作流，你的团队可以采取 与之前利用 SVN一样的方式来开辟 项目。

　　怎样 工作

　　Centralized Workflow

从长途 堆栈 (central repository)克隆工程到本地 堆栈 (local repository) — git clone

在本地 堆栈 编辑文件和提交更新 — git add和git commit

fetch长途 堆栈 已更新的commit到本地 堆栈 和rebase到已更新的commit的上面 —git fetch和git rebase 或 git pull --rebase

push本地 主分支(master branch)到长途 堆栈 — git push

　　管理辩论

　　File Conflicts

何时发生辩论 ：在开辟 者发布它们功能之前，他们必要 fetch长途 堆栈 已更新的commit到本地 堆栈 和rebase到已更新的commit的上面。偶然 ，本地 提交与长途 提交会发生辩论 ，git会停息 rebase过程来让你手动办理 辩论 。

怎样 办理 辩论 ：你可以利用 git status和git add来手动办理 归并 时辩论 。

　　Feature Branch Workflow

　　Feature Branch Workflow的重要 头脑 就是在开辟 每个功能时都应该创建一个独立的分支而不但 是利用 主分支。由于每个分支是独立且互不影响，这就意味着主分支不会包罗 broken code ，对连续 集成环境 是很有资助 的 。

　　怎样 工作

　　Feature Branch Workflow

仍旧 利用 长途 堆栈 (central repository)和主分支(master branch)仍记录 官方工程的汗青

开辟 者每次开辟 新功能时都创建一个新分支 — git checkout -b

Feature branches应该推送到长途 堆栈 (central repository) — git push

发送pull request来哀求 管理员可否 归并 到主分支(master branch)

发布新功能到长途 堆栈 (central repository)

　　Pull Request

　　Pull request是一种当开辟 者完成一个新功能后向其他团队成员发送关照 的机制。它的利用 过程如下：

　　开辟 者可以通过Github或Bitbucket发送pull request

　　Pull request on Github

其他的团队成员检察 、讨论和修改代码

项目维护者归并 新增功能分支到主分支(master branch)，然后关闭pull request

　　Gitflow Workflow

　　Feature Branch Workflow是一种非常机动 的开辟 方式。对于一些规模比力 大的团队，最好就是给特定的分支赋予差别 的脚色 。除了功能分支(feature branch) ，Gitflow Workflow还利用 独立的分支来预备 发布(preparing)，维护(maintaining), 和记录 版本(recording releases) 。下面我会逐个先容 这个几个分支：Historical Branches 、Feature Branches、Release Branches和Maintenance Branches。

　　Historical Branches

　　Historical Branches

master分支生存 官方发布汗青

develop分支衍生出各个feature分支

　　Feature Branches

　　Feature Branches

feature分支利用 develop分支作为它们的父类分支

当此中 一个feature分支完成后，它会归并 会develop分支

feature分支应该从不与master分支直接交互

　　Release Branches

　　Release Branches

release分支重要 用来整理 开释 、测试和更新文档

一旦develop分支得到 充足 的功能来发布时 ，你可以从develop衍生出一个release分支

一旦预备 好上架，release归并 到master分支而且 标记 一个版本号

别的 ，还必要 归并 回develop分支

　　Maintenance Branches

　　Maintenance Branches.png

maintenance分支用来快速给已发布产物 修复bug或微调功能

它从master分支直接衍生出来

一旦完成修复bug，它应该归并 回master分支和develop分支

master应该被标记 一个新的版本号

　　标记 Tags

　　利用 两个下令 来给master分支标记 版本号：

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

git push origin master --tags

　　Forking Workflow

　　Forking Workflow与以上讨论的工作流很差别 ，一个很紧张 的区别就是它不但 是多个开辟 共享一个长途 堆栈 (central repository)，而是每个开辟 者都拥有一个独立的服务端堆栈 。也就是说每个contributor都有两个堆栈 ：本地 私有的堆栈 和长途 共享的堆栈 。

　　Forking Workflow

　　Forking Workflow这种工作流重要 长处 就是每个开辟 者都拥有本身 的长途 堆栈 ，可以将提交的commits推送到本身 的长途 堆栈 ，但只有工程维护者才有权限push提交的commits到官方的堆栈 ，其他开辟 者在没有授权的环境 下不能push。Github很多 开源项目都是采取 Forking Workflow工作流。

　　怎样 工作

在服务器上有一个官方公共的堆栈

开辟 者fork官方堆栈 来创建它的拷贝，然后存放在服务器上

　　Fork official repository.png

当开辟 者预备 好发布本地 的commit时 ，他们push commit到他们本身 的公共堆栈

在本身 的公共堆栈 发送一个pull request到官方堆栈

维护者pull贡献者的commit到他本身 的本地 堆栈

检察 代码确保它不会粉碎 工程，归并 它到本地 堆栈 的master分支

push master分支到服务器上的官方堆栈

其他开辟 者应该同步官方堆栈 。

　　扩展阅读

Pro Git 简体中文版

atlassian Git Tutorials

看完本文有资助 ？请分享给更多人

关注「CPP开辟 者」，提拔 C/C++技能