Learn git and

github

Git 菜鸟饭团

Created by Leozhang2018 / @leozhang2018

问好,之前有看到各位在通过某些途径浏览 Git 的相关知识。相信在座各位至少已经看过了基本的操作，所以今天我就不会填鸭式赘述基本的操作命令（初始化，到add以及commit balabala...）,浪费大伙时间的同时，效率也非常之低下。我相信凭借大家的能力,通过互联网上的众多资源,也应该很快能掌握并适应基本的操作。所以接下来的三次分享里，我会着重分享一些我自己使用 Git 的相关经验技巧和 Git 中难以理解的知识点，以及在实际开发工作流程中使用 Git 可能会遇见的坑，如何去解决和驾驭它们。 OK,here we go.

leozhang2018

Front-End Developer

Blog / Github / 知乎 / V2ex

Version control

版本控制

例子:网页设计师或者经常从事制图的同学,可能会需要保存某一幅图片或页面布局文件的所有修订版本(渴望工具之一) CVS 可将某个文件回溯到之前的状态，将整个项目都回退到过去某个时间点的状态。比较文件的变化细节，查出修改者以及相关说明。

For example:

版本用户说明日期 V1.0.0: Tom Hanks 初始化重构代码库 May 10 V1.0.1: James Bond 增加支付模块 Jun 13 V1.0.2: Neo 修复交互模块漏动 Jul 15 V1.0.2: 隔壁老王垂死病中惊坐起,哥还有Bug没De完 Jul 18

什么是版本控制

记录文件变化
查阅版本修订
A system

首先,其次,最后。

本地版本控制系统

Local Version Control System

采用某种简单的数据库来记录文件的历次更新差异

集中化版本控制系统

Centralized Version Control System

让在不同系统上的开发者协同工作,比如(SVN), 单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。缺点:中央服务器的单点故障(宕机,停电) 无法提交更新，协同工作。中央服务器的磁盘发生故障，备份(无,不及时)导致丢失数据

分布式版本控制系统

Distributed Version Control System

完整镜像版本库中代码协同工作服务器宕机可以方便恢复同一个项目与不同工作小组的人协作,设定不同的协作流程

History of Git

前世今生

A part of

Linux kernel branch

Linux kernel 分支的部分截图,实际中要多得多。那么 Linux 内核团队是如何管理这么庞大而复杂的分支的呢?

The origin of distributed version control

Linux 内核开发团队使用 Bitkeeper

2002~2005

早期 Linux 团队使用 BitKeeper 维护相关代码,分布式版本控制系统的始祖（收费）。出于 Linux 是公共开源的项目考虑，开发 BitKeeper 的公司也就没有收费，作为工具提供给 Linux 社区使用。但是好景不长，Linux 团队仅仅使用了 BitKeeper 三年时间。

Andrew Tridgell

Samba 软件作者

Rsync 算法发明者

Andrew Tridgell，昵称垂居（Tridge），澳洲籍的计算机程序设计师，澳洲国立大学计算机科学博士。以创造 Samba 档案服务器以及 rsync (siNGk)算法著称。 Samba:让 UNIX 系统与 Windows 系统 SMB/CIFS 网络协议做链接的一种自由软件,在 Windows 与 UNIX 系列 OS 之间搭起一座桥梁，让两者的资源共享。rsync: Unix 下同步更新两处计算机的文件与目录并适当利用差分编码以减少数据传输的软件 BitMover 公司宣称 Tridgell 尝试通过逆向工程的方法破解 BitKeeper 的内部协议，决定收回 BitKeeper 的使用权。

" I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git' "

“我是个自负的混蛋,所有的项目都是围绕我自己命名的,之前是 'Linux' 现在则是 'Git' ” -- Linus Benedict Torvalds

Linus 本可向 BitMover 公司摊牌,承认自己的错误(背手下的锅),并且不再犯错，但是谈崩。决定自行开发版本控制系统，Git 诞生。基于（C，Perl，Unix shell）

Why git ?

本地化的版本管理 (完全分布式)
不污染子目录的 track 方式 (SVN每个子目录都要扔.svn)
强大的分支管理功能 (允许上千个并行开发的分支)
轻量简洁,唯快不破 (简单的设计)

Github 新的篇章

What is github?

由GitHub公司（曾称 Logical Awesome）的开发者使用 Ruby on Rails 所开发
用来存放使用 Git 版本控制的软件代码和内容项目
提供代码社交化功能的代码托管网站
全世界最大的同性交友网站

GitHub 同时提供付费账户和免费账户。都可以创建公开的代码仓库，付费账户也可以创建私有的代码仓库。GitHub 是最流行的 Git 访问站点。同时允许个人和组织创建和访问代码库以外,也提供了一些方便社会化软件开发的功能，包括允许用户跟踪其他用户、组织、软件库的动态，对软件代码的改动和 bug 提出评论等。提供了图表功能，用于显示开发者们怎样在代码库上工作以及软件的开发活跃程度。 Next,why 同性交友

Git rebase

2008-02 Github Inc 的服务正式上线

2007 年 10 月 1 日开始开发 ,吉祥物-章鱼猫(Octocat=Octopus（章鱼）+ Cat（猫）, Simon Oxley 设计)

提供代码托管服务的服务商

Bitbucket
Google Code (2016-1-25)
Gitcafe
Coding.net
Git@OSC
Etc ...

2015年3月12日，Google 宣布停止新项目的创建，8月24日变为只读状态，2016年1月25日 Google Code 将寿终正寝。

Break time

5 mins

Advanced Technology and Project

第一日 The Matrix

Installation and configuration

从安装和配置说起

以 Debian 系的 Ubuntu 为例

$ Sudo apt-get update

$ Sudo apt-get install git

(注:非源码安装方式)

源码安装好处:安装最新的版本缺点:需要编译不适合新手强烈推荐在 Linux 以及类 Unix 平台使用 Git (在 Unix 风格的 shell 中，可以使用本书中提及的复杂多行的命令) Windows:可以使用安装包 OS X:图形化的包管理工具 Macports 或者 homebrew

                    关键配置文件:

~/.gitconfig

.git/config

/etc/gitconfig

/etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。 ~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。当前项目的 Git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

用户信息

$ git config --global user.name "Leozhang2018"

$ git config --global user.email leozhang2018@gmail.com

(--global 参数读写 ~/.gitconfig 配置文件)

说明是谁提交了更新，更新内容一起被永久纳入历史记录

其他配置方向

指定文本编辑器 (Emacs or Vim)
差异分析工具
外部的合并与比较工具
格式化与空白

Demo time

Q&A

Any Questions?

One more thing

Free share

you-get

一个有趣而强大的命令行视频下载工具

summary

History of Git
Installation and configuration
Github tutorial

Reference

- 廖雪峰 Git 教程 - Github Training Class - Pro Git

参考资料,廖的教程不错,适合初学者以及刚入门速成的人,对于女生来说很友好。个人则强烈推荐 Pro Git (V1 老版本中文无障碍,V2 部分翻译中)

What is next ?

分支管理的注意事项
实际工作中利用分支进行开发的流程
Git 在其它环境中之 Git in Zsh
变基(Rebase)
初探 Gitlab

下次实际工作中利用分支进行开发的流程以及可能遇到的问题

See u next time

" I'll be back"

--Terminator T-800

THE END

- Get this slide - About you-get

第二日 The Matrix: Reload

Precautions,Process,Rebase

注意事项,工作流程,以及变基

What is next ?

分支管理的注意事项
实际工作中利用分支进行开发的流程
Git 在其它环境中之 Git in Zsh
变基(Rebase)
初探 Gitlab

下次实际工作中利用分支进行开发的流程以及可能遇到的问题

“某下午，大家正各自忙活着，忽然传来一声吼：“都别 pull 代码哈，master 上的代码不知被谁 revert 成两个月前的了！””

“（没错，就是百姓网网站的代码库）。立刻，锁部署系统（后来验证部署系统还是有足够防范不会把老代码直接发布的，但当时那个紧张呀），手工恢复代码库，几个人折腾了快一个小时，才安定下来开始找元凶：是一个实习生小朋友犯迷糊想 pull 却打成了 push --force，指向主 repo 的 master。” -- ElfeXu (百姓网架构师)

技术上出故障是必然的。能否体现一个公司是技术公司，重要看这几点：1）故障的恢复是否有技术含量，2）公司对故障的处理方式，如果是通过加更多的流程，或是通过加更多的权限管控，或是通过处罚犯错误的人，或是上升到员工意识形态上，而不是去用更好的技术来解决，那么这个公司不会是个技术公司。左耳朵耗子

fork->edit->pull request->

code review->merge

保险的做法

典型分支流水线

Classic Work Silos

只在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。这样，在确保这些已完成的特性分支（短期分支，比如之前的 iss53 分支）能够通过所有测试，并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布。

拥有多个特性分支的提交历史

特性分支对任何规模的项目都适用。特性分支是一种短期分支，它被用来实现单一特性或其相关工作。也许你从来没有在其他的版本控制系统（VCS）上这么做过，因为在那些版本控制系统中创建和合并分支通常很费劲。然而，在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。

Git Rebase

分支的衍合

做一个Merge 和 rebase 的分支对比

Which do you prefer?

假设合并之前是这样

使用 Merge 命令合并后

使用 Rebase 的话

如果是 rebase 的方式，就不會有 G 的合并点

做一个 compare

有 conflict 怎么办? rebase 跟 merge 类似，发现 conflict 会暂停 rebase 动作，需要你手动修复后，然后才可以继续工作。这也是 rebase 比 merge 复杂一点的地方：merge 如果发生 conflict，你只需要解決冲突一次，然后 commit 出去就完成了。而 rebase 的 conflict 可能會发生在上述步骤 4 的每一次重新套用上，所以可能需要解決冲突好几次 (rebase 时所谓的解决冲突，其实是直接修改之前的变更內容，所以上图中变成 D’ 跟 E’ )。

A question?

那么问题来了，如果你修改比较多，預期會有较多的 conflict，建议用 merge (不过，如果是多次大范围式的修改，那是不是应该一开始就多开一个 branch 来做呢?)。如果修改范围较小，预期不会有太多的 conflict，则建议可以加上 rebase 参数。

For example:

一个有意思的问题例子

Github 上存在主分支, 本地需要修改多个功能和 bug , 于是在多个分支开发不同的功能, 然后合并提交.. 合并和提交的顺序不是确定的, 因此不能简单直接用 merge 每次一个个叠加. 有时我用 rebase, 但有发现 commit 顺序不是时间顺序, 到线上被 merge 以后也不是非常清晰面对这样的场景, 用怎样的方式管理会更合适呢?

How to fix it:

$ git checkout work (去自己的工作分支工作)
$ git commit -a (提交工作修改)
$ git checkout master (切换到主分支)
$ git pull (获取远程最新修改，此时不会产生冲突)

git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：

How to fix it:

$ $ git checkout work (回到工作分支)
$ git rebase master (用rebase合并主干的修改，如果有冲突在此时解决)
$ git checkout master (切换到主分支)
$ git merge work (合并工作分支的修改，此时不会产生冲突)
$ git push提交到远程版本库

这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突

Demo time

关于其它

Q&A

Any Questions?

THE END

- Get this slide - Get online source

Online Reference:

Learn git and github Git 菜鸟饭团 Created by Leozhang2018 / @leozhang2018 问好,之前有看到各位在通过某些途径浏览 Git 的相关知识。相信在座各位至少已经看过了基本的操作，所以今天我就不会填鸭式赘述基本的操作命令（初始化，到add以及commit balabala...）,浪费大伙时间的同时，效率也非常之低下。我相信凭借大家的能力,通过互联网上的众多资源,也应该很快能掌握并适应基本的操作。所以接下来的三次分享里，我会着重分享一些我自己使用 Git 的相关经验技巧和 Git 中难以理解的知识点，以及在实际开发工作流程中使用 Git 可能会遇见的坑，如何去解决和驾驭它们。 OK,here we go.

gitslide

xiyouant

gitslide

1 2 (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/platform.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();

gitslide

Learn git and

github

Git 菜鸟饭团

leozhang2018

Front-End Developer

Version control

For example:

什么是版本控制

本地版本控制系统

集中化版本控制系统

分布式版本控制系统

History of Git

A part of

Linux kernel branch

Andrew Tridgell

Why git ?

Github 新的篇章

What is github?

Git rebase

提供代码托管服务的服务商

Break time

第一日 The Matrix

Installation and configuration

其他配置方向

Demo time

Q&A

Any Questions?

One more thing

Free share

you-get

Supported Sites

summary

Reference

What is next ?

See u next time

--Terminator T-800

THE END

第二日 The Matrix: Reload

Precautions,Process,Rebase

What is next ?

fork->edit->pull request->

code review->merge

典型分支流水线

拥有多个特性分支的提交历史

Git Rebase

做一个Merge 和 rebase 的分支对比

假设合并之前是这样

使用 Merge 命令合并后

使用 Rebase 的话

做一个 compare

A question?

For example:

How to fix it:

How to fix it:

Demo time

关于其它

Q&A

Any Questions?

THE END

Online Reference:

1 2