GIT在iOS开发中的使用

前言

在

iOS

开发中，很多公司对项目的版本控制管理都使用了

git

，当然也有部分公司使用的是

svn

。当年我最初接触的是

svn

，觉得使用起来挺方便的，但是每次切分支都需要下载一份新的代码起来，这实在太麻烦了，而且公司的网络下载一个项目的所有资源起来也有数百

M

，这还用工作么？

当年，第一次听说

github

的时候，就听说是使用

git

来管理的，可是那时的我感觉好复杂，不知道如何入手。如今，对

git

的使用可以说是很熟练了，不管是使用命令操作还是直接使用

GUI

界面工具操作。

就让我带着还不会使用

git

的同志，跨过那些我曾经走过的坑…

创建新仓库

如果我们在本机上想要创建一个新的

git

仓库，可以直接使用下面的命令：

1 2 3

git init

还有一种命令可以创建仓库：

1 2 3

git init --bare

我相信大家一定会疑问，这两者有什么区别呢？从字面上看，

bare

就是赤裸裸的意思，也就是说生成用于记录版本库历史记录的

.git

目录下面的文件而不会包含实际项目源文件的拷贝。进入版本目录,会发现只有

.git

目录下的文件。这个版本库里面的文件都是

.git

目录下面的文件,把原本在

.git

目录里面的文件放在版本库的根目录下面;换句话说,不使用

--bare

选项时,会生成

.git

目录以及其下的版本历史记录文件,这些版本历史记录文件就存放在

.git

目录下;而使用

--bare

选项时,不再生成.git目录,而是只生成.git目录下面的版本历史记录文件,这些版本历史记录文件也不再存放在

.git

目录下面,而是直接存放在版本库的根目录下面。

这么多说明是不是头晕了？我们来来测试一下：

1 2 3 4 5 6 7 8 9

cd Desktop/ mkdir testgit1 cd testgit1 git init ls cd .git ls

这里在桌面创建一个目录叫

testgit1

，进入到

testgit1

目录下，然后执行

git init

来初始化一个仓库。然后，就会生成一个

.git

目录，然后查看当前目录是否有文件？第一个

ls

命令是不是什么也没有？是的，默认

.git

目录是隐藏的。我们进入到

.git

目录下，查看：

1 2 3 4

HEAD config hooks objects branches description info refs

下面简单说明一下这几个东东分别干嘛用：

HEAD

是个头指针，在处理版本切换时，就是这个指针前移、后移等，因此只会生成快照而已，不会重新下载完整的一份代码，所以切换只需要几秒钟就可以在不同的分支上开发了。是不是很方便？

config

是配置文件，想要看看内部有什么东西，可以直接

vi config

查看。

hooks

叫钩子，主要是用于控制

commit

、

push

等操作动作，若需要深入了解，可百度，这个东西也是有很深的学问的。

objects

是存储所有的

git

对象，关于这个也可以百度阅读相关文章，内容也很多。

branches

自然是分支的意思，用于管理分支，里面会有所有的分支。

description

自然是描述信息

info

这个目录就不清楚具体是干嘛用了

refs

这个目录有

heads

和

tags

，前者不清楚其用意，后者就是标签，比如我们支持

cocoapods

的开源库中升级就需要设置

tag

，对应版本。

用

git init

初始化的版本库，用户可在该目录下执行所有

git

操作，但别的用户在将

push

上来的时候容易出现冲突。因此，实际中会将远程服务器端创建一个仓库时，才会使用

--bare

，而我们个别用户在创建仓库时，不使用

--bare

。

克隆版本

如果是本地的

git

仓库，就直接使用下面的命令，其中

/path/to/repository

是绝对路径：

1 2 3

git clone /path/to/repository

如果是在远程服务器这边的仓库，可以用这样的命令。其中

username

公司给你开的

git

用户，

host

是你们公司放置项目代码的服务器，

/path/to/repository

是远程

git

仓库的访问路径：

1 2 3

git clone username@host:/path/to/repository

工作流

首先，我们需要理解

git

版本控制的工作流：

本地仓库由

工作目录

，它持有实际文件；第二个是

缓存区

，它像个缓存区域，临时保存你的改动；最后是

HEAD

，指向你最近一次提交后的结果。

看看官方的图解：



其流程：当前

working dir

通过

add

命令添加到

stage

缓存区中，再通过

commit

命令提交，

HEAD

就指向了这次提交的结果。

add命令添加

使用下面的命令添加到缓存区，其中第一行代码是只提交一个文件到缓存区，而第二行代码是添加所有有改动的文件到缓存区：

1 2 3 4

git add <filename> git add *

commit命令提交本地

然后我们就可以通过

commit

提交，其中

-m

选项是

comment

的意思，也就是注释，后面跟着一行注释说明：

1 2 3

git commit -m "代码提交信息"

执行完

commit

后，现在，所做的改动已经提交到了

HEAD

，但是还没到提交到远端仓库。

push命令推到远端

你的改动现在已经在本地仓库的

HEAD

中了，执行如下命令以将这些改动提交到远端仓库：

1 2 3

git push origin master

可以把

master

换成你想要推送的任何分支。 如果当前我们不是在主干上开发，我们提交的代码是要提交到当前正在开发的分支上。假设当前正在开发的分支名称叫：Double11Activity表示双11活动分支。那么我们所做的改动应该推送到

Double11Activity

分支上。

1 2 3

git push origin Double11Activity

remote add添加远端仓库

如果你还没有克隆现有仓库，并欲将你的仓库连接到某个远程服务器，你可以使用如下命令添加：

1 2 3

git remote add origin <server>

其中

server

就是我们远程

git

服务器的访问路径。比如：

1 2 3

git remote add origingit@182.92.160.41:/data/git/demo.git

查看仓库是否已经添加到远端

git

仓库，可使用下面的命令：

1 2 3

git remote -v

如果出现类似这样：

1 2 3 4

origin git@server:/Data/git/ios/demo.git (fetch) origin git@server:/Data/git/ios/demo.git (push)

假设系统是

CentOS

系统，其中，

git

是用户，

server

是服务器地址，

/Data/git/ios/demo.git

是具体的项目仓库目录访问地址。

有了这些，我们就能够将本地改动推送到所添加的服务器上去了。

pull命令拉代码

想想多人同时开发时，除了你自己会发动代码之外，其他同事也会改动代码并提交到远端仓库，因此我们每次在提交之前，都应该先

pull

一下，将其他同事最新的代码拉下来。如果有冲突，则需要先解决冲突，然后合并，且在

xcode

编译运行通过，再将代码推送到远端仓库。

拉最新代码的命令就很容易了：

1 2 3

git pull

如果出现冲突，一定要解决，否则工程就打不开。如果解决不好，且在本机没有在

xcode

上跑通，那么一旦提交到远端，其他同事一拉代码，就会导致无法打开，或者编译不通过，会影响他人的工作。

分支branch

分支是用来将敏捷开发的根本。在你创建仓库的时候，

master

是“默认的”，通常用做

主干

。在其它分支上进行开发，完成后再将它们合并到主干上。



创建一个叫做

feature_x

的分支，并切换过去：

1 2 3

git checkout -b feature_x

如果只是创建一个分支而不自动切换到该分支上，可以这样：

1 2 3

git checkout feature_x

想要切换到

master

上，这样：

1 2 3

git checkout master

删除分支：

1 2 3

git branch -d <分支名>

通常在开发中，每一期的需求在开发之前，都需要建立一个新的分支，并在这个分支上开发。创建之后，我们还需要推送到远端，不然其他同事无法一起参与开发。

1 2 3 4

git branch -b <branchname> git push origin <branchname>

合并分支：

1 2 3

git merge <branch>

合并方法：如果要将分支

A

合并到分支

B

，那么应该这样：先切换到

B

分支，然后执行命令：

1 2 3

git merge A

也就是说，

A

要合并

B

，就要先切换到

A

分支，再执行合并命令。如果是

B

要合并

A

，就需要先切换到

B

分支，然后再合并

A

分支。

对于多人同时开发，尤其多团队敏捷开发的大团队，代码合并是非常麻烦的事。今天下午将其他团队刚上线的版本合并到主干，再将主干合并到当前我们团队与其他团队抽人共同开发的分支上，解决冲突就花了4个小时。

好在没有没有动

storybard/xib

这些地方，合并也就几个小时就可以了。如果上一期开发做了很多的界面改动，而这个界面原来是由

sb/xib

开发的话，合并过来就困难了，那些是很难读懂的一串串的东西，不知如何调。因此，对于大团队开发，真的不建议使用

xib/sb

来开发。

合并之前，可以先查看当前分支与待合并过来的分支的有什么不同：

1 2 3

git diff <source_branch> <target_branch>

注意事项

通常上线的分支都是

master

，也就是主干，因此在实际开发中，必须保证主干永远是最干净的，只能将主干代码合并到其他分支，然后测试通过并上线后，再合并到主干上

推荐git界面软件：SourceTree

这个软件对于那些不懂命令，也不想用命令的开发者来说，这个软件就是一大福利。



我们可以直接将本地的仓库直接添加进来，也可以克隆远端仓库到本地。点击新仓库就可以添加了，其中有四个选项，我们会选择第一个：从URL克隆，也就是

git

访问地址。



这里面有很多个操作，每个就是对应于一个命令，如果不想使用命令操作，可以直接使用这个。

在实际开发中，解决冲突时，我还是要使用这个软件来解决的，因此冲突文件有时候会达到上百个类文件冲突，要花一天时间来解决冲突。