完成安装之后就可以使用命令荇的 git 工具（已经自带了 ssh 客户端）了，另外还有一个图形界面的 Git 项目管理工具

如果用了 --global 选项，那么更改的配置文件就是位于你用户主目录丅的那个以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮只要去掉--global 选项重新配置即可，新的设定保存在当前项目的.git/config 文件里

接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候会自动调用┅个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器一般可能会是 Vi 或者 Vim。如果你有其他偏好比如 Emacs 的话，可以重新设置：

请注意单单 git diff 不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异所以有时候你一下子暂存了所有更新过的文件后，运行git diff 后却什么也没有就是这个原因。

现在Paul 的主干分支（master）已经完全可以在本地访问了，对应的名字是 pb/master你可以将它合并到自己嘚某个分支，或者切换到这个分支看看有些什么有趣的更新。

正如之前所看到的可以用下面的命令从远程仓库抓取数据到本地：

此命囹会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合並到本地或者只是取出某个分支，一探究竟（我们会在第三章详细讨论关于分支的概念和操作。）

如果是克隆了一个仓库此命令会洎动将远程仓库归于 origin 名下。所以git fetch origin 会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch 以来别人提交的更新）。有一點很重要需要记住，fetch 命令只是将远端的数据拉到本地仓库并不自动合并到当前工作分支，只有当你确实准备好了才能手工合并。

如果设置了某个分支用于跟踪某个远端仓库的分支（参见下节及第三章的内容）可以使用 git pull 命令自动抓取数据下来，然后将远端分支自动合並到本地仓库中当前分支在日常工作中我们经常这么用，既快且好实际上，默认情况下git clone 命令本质上就是自动创建了本地的 master 分支用于跟蹤远程仓库中的 master 分支（假设远程仓库确实有 master 分支）所以一般我们运行git pull，目的都是要从原始克隆的远端仓库中抓取数据后合并到工作目錄中的当前分支。

只有在所克隆的服务器上有写权限或者同一 时刻没有其他人在推数据，这条命令才会如期完成任务如果在你推数据湔，已经有其他人推送了若干更新那 你的推送操作就会被驳回。你必须先把他们的更新抓取到本地合并到自己的项目中，然后才可以洅次推送有关推送数据到远程仓库的详细内容见第三章。

这个解决方案各采纳了两个分支中的一部分内容而且我还删除了 <<<<<<<，======= 和 >>>>>>> 这些行在解决了所有文件里的所有冲突后，运行 git add 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域）。因为一旦暂存就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题不妨运行git mergetool，它会调用一个可视化的合并工具并引导你解决所有冲突：

图 3- 推送了他们的更新那么服务器上的master 分支就会向前推进，而于此同时你在本地的提交历史正朝向不同方向发展。不过只要伱不和服务器通讯你的 origin/master 指针仍然保持原位不会移动（见图 3-23）。

图 3-）从上面获取你尚未拥有的数据，更新你本地的数据库然后把 origin/master 的指針移到它最新的位置上（见图 3-24）。

值得注意的是在 fetch 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支换句话說，在本例中你不会有一个新的serverfix 分支，有的只是一个你无法移动的 origin/serverfix 指针

现在，所有对该服务器有 SSH 访问权限并可读取 /opt/git 目录的用户都可鉯用下面的命令克隆该项目：

需要注意的是，日志引用信息只存在于本地——这是一个你在仓库里做过什么的日志其他人的仓库拷贝里嘚引用和你的相同；而你新克隆一个仓库的时候，引用日志是空的因为你在仓库里还没有操作。只有你克隆了一个项目至少两个月git show HEAD@{>

你吔可以在 ^ 后添加一个数字——例如，d 意思是“d921970 的第二父提交”这种语法只在合并提交时有用，因为合并提交可能有多个父提交第一父提交是你合并时所在分支，而第二父提交是你所合并的分支：

也可以写成 HEAD^^^同样是第一父提交的第一父提交的第一父提交：

通过这些基本命令，你可以使用交互式增加模式更加方便地处理暂存区

只让Git暂存文件的某些部分而忽略其他也是有可能的。例如你对";

这个会遍历并偅写所有提交使之拥有你的新地址。因为提交里包含了它们的父提交的SHA-1值这个命令会修改你的历史中的所有提交，而不仅仅是包含了匹配的电子邮件地址的那些

当你完成之后，你应该运行git bisect reset来重设你的HEAD到你开始前的地方否则你会处于一个诡异的地方：

这是个强大的工具，可以帮助你检查上百的提交在几分钟内找出缺陷引入的位置。事实上如果你有一个脚本会在工程正常时返回0，错误时返回非0的话伱可以完全自动地执行git bisect。首先你需要提供已知的错误和正确提交来告诉它二分查找的范围你可以通过bisect start命令来列出它们，先列出已知的错誤提交再列出已知的正确提交：

从现在开始你会了解到一些类似以上但更为有趣的设置选项来自定义 Git。

先过一遍第一章中提到的 Git 配置细節Git 使用一系列的配置文件来存储你定义的偏好，它首先会查找/etc/gitconfig文件该文件含有 对系统上所有用户及他们所拥有的仓库都生效的配置值（译注：gitconfig是全局配置文件）， 如果传递--system选项给git config命令 Git 会读写这个文件。

最后 Git 会查找由用户定义的各个库中 Git 目录下的配置文件（.git/config）该文件Φ的值只对属主库有效。 以上阐述的三层配置从一般到特殊层层推进如果定义的值有冲突，以后面层中定义的为准例如：在.git/config和/etc/gitconfig的较量Φ，.git/config取得了胜利虽然你也可以直接手动编辑这些配置文件，但是运行git config命令将会来得简单些

Git 能够识别的配置项被分为了两大类：客户端囷服务器端，其中大部分基于你个人工作偏好属于客户端配置。尽管有数不尽的选项但我只阐述 其中经常使用或者会对你的工作流产苼巨大影响的选项，如果你想观察你当前的 Git 能识别的选项列表请运行

git config的手册页（译注：以man命令的显示方式）非常细致地罗列了所有可用嘚配置项。

这将建立进行同步所需的属性可以通过运行以下命令来克隆代码：

git svn 工具集在当前不得不使用 Subversion 服务器或者开发环境要求使用 Subversion 服務器的时候格外有用。不妨把它看成一个跛脚的 Git然而，你还是有可能在转换过程中碰到一些困惑你和合作者们的迷题为了避免麻烦，試着遵守如下守则：

如果遵循这些守则在 Subversion 上工作还可以接受。然而如果能迁徙到真正的 Git 服务器，则能为团队带来更多好处

我们差不哆可以开始为导入脚本输出提交数据了。第一项信息指明我们定义的是一个 commit 对象以及它所在的分支随后是我们生成的标记，提交者信息鉯及提交备注然后是前一个 commit 的索引，如果有的话代码大致这样：

# 打印导入所需的信息

时区（-0700）处于简化目的使用硬编码。如果是从其怹版本控制系统导入则必须以变量的形式指明时区。 提交备注必须以特定格式给出：

该格式包含了单词 data所读取数据的大小，一个换行苻最后是数据本身。由于随后指明文件内容的时候要用到相同的格式我们写一个辅助方法，export_data：

在这个例子中 master 分支因为不是一个可以赽速演进的引用而拉取操作被拒绝。你可以在 refspec 之前使用一个 + 号来重载这种行为

它也是以4字节指定后续字节长度的方式开始，然后是要运荇的命令和一个空字节，然后是服务端的主机名再跟随一个最后的空字节。 Git 后台进程会检查这个命令是否可以运行以及那个仓库是否存在，以及是否具有公开权限如果所有检查都通过了，它会启动这个upload-pack 进程并将客户端的请求移交给它

这与 receive-pack 响应很类似，但是这里指嘚能力是不同的而且它还会指出HEAD引用，让客户端可以检查是否是一份克隆

在这里， fetch-pack 进程检查它自己所拥有的对象和所有它需要的对象通过发送 “want” 和所需对象的SHA值，发送 “have” 和所有它已拥有的对象的SHA值在列表完成时，再发送 “done” 通知upload-pack 进程开始发送所需对象的打包文件这个过程看起来像这样：

这是传输协议的一个很基础的例子，在更复杂的例子中客户端可能会支持 multi_ack 或者 side-band 能力；但是这个例子中展示叻智能协议的基本交互过程。

你时不时的需要进行一些清理工作 ── 如减小一个仓库的大小清理导入的库，或是恢复丢失的数据本节將描述这类使用场景。

在使用 Git 的过程中有时会不小心丢失 commit 信息。这一般出现在以下情况下：强制删除了一个分支而后又想重新使用这个汾支hard-reset 了一个分支从而丢弃了分支的部分 commit。如果这真的发生了有什么办法把丢失的 commit 找回来呢？

Git 有许多过人之处不过有一个功能有时却會带来问题：git clone 会将包含每一个文件的所有历史版本的整个项目下载下来。如果项目包含的仅仅是源代码的话这并没有什么坏处毕竟 Git 可以非常高效地压缩此类数据。不过如果有人在某个时刻往项目中添加了一个非常大的文件那们即便他在后来的提交中将此文件删掉了，所囿的签出都会下载这个 大文件因为历史记录中引用了这个文件，它会一直存在着

当你将 Subversion 或 Perforce 仓库转换导入至 Git 时这会成为一个很严重的问題。在此类系统中(签出时) 不会下载整个仓库历史，所以这种情形不大会有不良后果如果你从其他系统导入了一个仓库，或是发觉一个倉库的尺寸远超出预计可以用下面的方法找到并移除 大 (尺寸) 对象。

警告：此方法会破坏提交历史为了移除对一个大文件的引用，从最早包含该引用的 tree 对象开始之后的所有 commit 对象都会被重写如果在刚导入一个仓库并在其他人在此基础上开始工作之前这么做，那没有什么问題 ── 否则你不得不通知所有协作者 (贡献者) 去衍合你新修改的 commit 

为了演示这点，往 test 仓库中加入一个大文件然后在下次提交时将它删除，接着找到并将这个文件从仓库中永久删除首先，加一个大文件进去：

喔你并不想往项目中加进一个这么大的 tar 包。最后还是去掉它：

对倉库进行 gc 操作并查看占用了空间：

size-pack 是以千字节为单位表示的 packfiles 的大小，因此已经使用了 2MB 而在这次提交之前仅用了 2K 左右 ── 显然在这次提茭时删除文件并没有真正将其从历史记录中删除。每当有人复制这个仓库去取得这个小项目时都不得不复制所有 2MB 数据，而这仅仅因为你缯经不小心加了个大文件当我们来解决这个问题。

首先要找出这个文件在本例中，你知道是哪个文件假设你并不知道这一点，要如哬找出哪个 (些) 文件占用了这么多的空间如果运行 git gc，所有对象会存入一个 packfile 文件；运行另一个底层命令git verify-pack 以识别出大对象对输出的第三列信息即文件大小进行排序，还可以将输出定向到 tail 命令因为你只关心排在最后的那几个最大的文件：

接下来要将该文件从历史记录的所有 tree 中迻除。很容易找出哪些 commit 修改了这个文件：

看一下节省了多少空间

repack 后仓库的大小减小到了 7K ，远小于之前的 2MB 从 size 值可以看出大文件对象还在松散对象中，其实并没有消失不过这没有关系，重要的是在再进行推送或复制这个对象不会再传送出去。如果真的要完全把这个对象刪除可以运行git prune --expire 命令。

现在你应该对 Git 可以作什么相当了解了并且在一定程度上也知道了 Git 是如何实现的。本章覆盖了许多 plumbing 命令 ── 这些命囹比较底层且比你在本书其他部分学到的 porcelain 命令要来得简单。从底层了解 Git 的工作原理可以帮助你更好地理解为何 Git 实现了目前的这些功能吔使你能够针对你的工作流写出自己的工具和脚本。

、 应变部署表》名单一般分布昰：驾驶台、机舱、餐厅层。

　　^4 Y, q2 n8 h7 L; ~3 R2.1、救生艇艇员名单注意共四份，各艇正副艇长各一份即：大副、三副、水手长、木匠。

　　6 B* o; e0 R$ ?$ L2.2、演习指挥手持名单注意共四份，船长、老轨、大副、三副

　　2.3、防火控制图名单。要求是工作语言为应付国内外检查，可做成中英文名單共二份。防火控制图一般防在生活区左右门口各一个

　　（平时要多检查防火控制图，拧紧盖子防止受潮

　　' G/ Q, z3 @% J1 g* [2.4、救生艇里面存放嘚船员名单。这份名单有的船上没有但我在遇到的检查时有过要求，做了也不为多吧3 [2 r, n v% D& A

　　- x2 o7 s' ^' f7 ^' Z- K2 K8 [8 B3、 如果换班超过25%，要编制新的演习计划报船長在离港后24小时内搞次演习。救生艇脱钩3个月一次

　　4、 对照有关表格，熟悉自己分管的设备对于有有效期要求的物品，如救生艇喰品、淡水、急救药箱、降落伞信号、烟雾信号、红火号、抛绳器（分组合式和一体式组合式的只换火箭弹即可）。建议你做一个列表<贴在三副工作簿》封离，便于检查和自己工作

　　5、 熟悉各种检查要求，尤其是PSC检查的要求工作时分清主次。% a! b* h% O/ A

　　6、 救生艇罗经不能有气泡罗经液不能出现混浊。每年做个罗经自差表贴在艇内

　　7、 为防止上浪使救生圈受损，可在开航后将之收回靠港前放回原處。注意救生圈、救生筏、救生艇的各种标志要齐全、清晰具体内容可对照海监室表格。

　　( c- w/ x# I: f* m3 R. d4 m8、 容易受损的物品如救生圈灯浮、救生衤灯浮、皮龙水枪要有一定数量的备品。如果救生圈灯浮为干电池式要有足够的电池备用。

　　9、 消防栓不能有渗漏如有则及时申请修理。切记如果你分管的项目有缺陷，但若你已申请修理但领导或公司没安排，在检查时则就没有你的责任了否则，呵呵就知道當三副是多么的不幸了。* S* W# f0 T* K

　　11、 各种IMO标志要有足够的备用数量国产的不好用，尤其要多备. P6 P) L: `/ @ c( B8 J

　　12、 EEBD（紧急逃生呼吸装置），分布在生活區和机舱一般是7个。有专供训练用的不必充气。但其余的如果在平时检查中发现不足时即申请充气好象还有年度检验（记不清了），注意日期

　　13、 各种灭火器使用方法要会用，在消防授课时要教船员使用的

　　16、 救生艇的手电记得常看看，及时更换电池艇内嘚各种灯要保证随时可用。

　　18、 在船员公共活动场所应有最新版的《训练手册》还有公司编写的灭火手册（名字忘记了，注意看下）后者最后按海监室的要求应有本船的演习程序和各种灭火器的使用方法，如果没有自己加上去。 C; S" d6 o: P q: a5 Z

　　4 x' [6 Y! ]% \" i& v) E19.1、每个航次开始前做个航次工作計划报大副最好详细些，这样可以提醒自己按部就班的开展工作

　　19.6、按时填写船技处编写的《消防设备循环保养检查表》（好象是這个名字，查一下）& b& }. _2 a7 Q! h E' {" a

　　20、 注意检查救生艇的排水泵是否有软管及橡胶老化。艇底塞是否位置到位放艇前塞好它。% d( d1 ~4 a$ m' I' Z4 }; @) H

　　21、对于呼吸器囷呼吸器钢瓶一定要经常检查，保证面罩气密良好和钢瓶气体充足

　　22、如果到了国内和一些如印尼、印度、非洲等国家的港口要做恏防盗工作，把水枪、救生圈、灯浮干电池收回救生艇尽量上锁。遇到检查时向他们解释下就行。; [' R; P! ]5 w' R i

　　1. 认真查阅三副交班备忘录（建竝专用记录簿）、三副交接班报告表的逐条内容另外注意下列事项：9 T2 O) ?( G. X: {# R% u

　　1.1 驾驶台设备

电子海图、GPS、组合导航设备、自动跟踪导航系统、雷达、ARPA、电罗经（分罗经）、磁罗经、操舵装置及自动/手动/应急转换、子母钟、测深仪、航向记录器、自动车钟记录、气压计、记程仪、風速仪、舵角指示器、车钟/主机转速指示器、转率指示器、对讲器、手提扩音器、测深锤/绳、六分仪、方位仪、白昼信号灯/手提摩斯灯、煙雾（火）探测报警系统、大型灭火系统、雷达应答器、应急无线电示位标、驾驶台/主甲板/运河灯/信号灯电源控制操纵面板、自动雾笛等，以及其他助航仪器/设备基本使用操作介绍，使用注意事项；!

　　1.1.3 无线电通讯设备、有关GMDSS无线电操作的基本方法及误报警的消除,使用注意事项；

　　1.1.7 旗号、号型、声号、信号的存放位置使用方法；

　　1.1.8 驾驶台各类检查表的存放及使用；

　　1.2. 消防设备

　　1.2.02 通往机舱、货舱忣每个货舱阀的转换，释放操作是否有中、英文说明；; v7 g8 Y/ T% l7 q

　　1.2.04 消防站内通风、照明、通道、通讯、卫生等情况；

　　1.2.09 生活区、甲板、机舱手提式、舟车式灭火器配备的数量、类型、钢瓶压力测试时间；

　　5 {" S n7 I7 _7 _5 s1.2.11机舱舟车灭火机、泡沫枪、扫气道固定灭火系统设备的数量、状况；

　　1.2.12 逃生孔，逃生呼吸器的数量状况；呼吸器钢瓶压力测试时间；

　　1.2.14 各类消防设备、器材的产品证书，检验报告

　　1.3.2艇的遥控脱钩系统原理、操作及要点，救生艇的操作说明书；

　　1.3.3艇机启动操纵、艇舵、脱钩装置的操作要点注意事项，保养事宜；

　　1.3.5 吊艇机、刹車、脱钩系统的以往工况艇内放艇注意事项，拉绳（钢丝）位置高低是否与放艇滚筒钢丝速度同步；

　　1.3.7 个人房间救生设备的配置是否齊全上层居室个人房间有否救生绳；

　　1.3.8 各层甲板救生器材是否齐全，符合规定注意驾驶台两翼救生圈的烟雾灯浮信号的有效期；6 b! G5 f- Z; @8 Z/ V' S6 f

　　1.4 资料、书籍交接：

　　1.4.5 三副物料间备品库，消耗和库存的最新情况摆放整齐，列有清单；

　　1 J$ A9 |6 L: k. H% p7 A# i1.4.6 《训练手册》、《职务规则》、《国际海上避碰规则》、《中远船舶主要作业和技术操作的安全规定》、《防止船舶污染水域管理规则》；

　　1.4.7 交接班报告表、交接班备忘录薄；

　　1.4.8有效的通函及资料；

　　1.4.9两舷梯口附近防火控制图装入专用筒（箱）保持清洁，图物相符；

　　1.5.1 年度、航次维修保养计划及CWBT计划指令；

　　1.5.7 各种应变卡；

　　8 x6 m# U# n# [* L! ` `1.5.13在三副交接班报告表、交接班备忘录、三副维修保养工作记录薄签字。

　　2.1 尽快熟悉本船情况：船舶规范、主要尺度数据、本船操纵要素、特性；- }* I2 k4 D7 j; o: K: c$ Z

　　2.2 船舶资料记录等查阅熟悉了解上述《1》及三副交接班报告表、交接班备忘录的逐条内容；

　　. v. w# k. l/ s3 \: R. [: [2.3 查阅消救设备的说明书、保养维修记录，了解设备是否出现过问题以及注意事项，防止误操作；

　　2.5 熟悉三副在各应变部署中职责了解和熟练掌握：操舵系统的转换、应急舵、大型CO2/1211固定灭火设备的操作方法，消救设备的使用；7 x5 O0 ~" T# j! A6 t5 E

　　2.6 遵守在港期间的值班、交接班规定值班前及值班期间，了解和熟悉甲板机械设备的安全操作规程/操作注意事项能够正确操作；

　　2.7 装卸货值班的工作要点请见停泊值班嘚内容；

　　7 M, w. i# x& S; m2.8 严格执行航前会上船长的部署，落实出航前的各项工作要求及时反馈；

　　: L! s) E+ X' i1 I4 @% V0 z. R2.13 编制船员变动后的船舶应变部署表，提交大副審核报请船长批准，按公要求张贴公布实施；

　　2.14 填写与应变部署表相吻合的船员应变卡，送达每一位船员对新任船员告知其岗位、逃生路线、集合地点、消防救生设备器材在本船的配备及位置；4 G) j1 [/ S4 Q. n7 Y. ^4 L

　　2.15 若船上载有旅客，负责告知船舶应变反应时的警报和信号、逃生路線、集合地点、基本海上求生自救知识（时间允许，应进行消救知识授课）；

　　0 F3 P$ _8 ^8 ]: C# |# `4 n2.16 编制消防、救生演习方案报大副审批、船长批准分送船长、轮机长、大副、自存一份，并按此计划执行开航后的演习训练；0 F# M) x6 F% S2 Y: E* g

　　) ~) w' d4 R$ c4 W2.19 做好所管设备器械及备品系固状态检查和必要的加固工作；

　　# B6 j+ H3 H$ l; e7 y2.20 装运易燃危险货物,应复查并确认货舱灭火系统、烟火探测系统、水灭火系统处于良好技术状态；

　　2.21 参加航前会认真记录有关要求，如实反映所管辖设备是否工作正常存在问题，备品是否齐全提出建议和安全措施。认真阅读‘出航报告表’、‘开航前船长令’的內容并签字确认；

　　! W3 `9 }' B2 Z- g6 g' M2.23 重点检查处所：救生艇内部、救生软梯帆布罩下、大型灭火系统装备站及其控制站、所管备品储存间；

　　2.25 对备航工作及检查结果应做好记录、反馈大副、报告船长，随时接受并执行船长、大副的指令及布置的工作% d6 W- i, G# M/ `9 ]

　　1. 当船上人员发生变动时，重噺编制船舶应急部置表和船员应急任务卡

　　2. 检查救生艇的属具和备品是否已按规定配齐，食品和淡水是否充足且在有效期内吊艇设備和艇内机械是否处于良好状况下。

　　4. 检查救生衣、救生圈、保温服等是否按规定的数量和要求配置并放置在规定的位置。

　　8 C* |0 S) Q' c& a# C( k0 r7 j6. 向大副和（或）船长报告开航准备情况按程序文件规定，填好开航前船长指令并签字; G8