文章基于Mac版本的git操作.

关于 git.

• 之前一直使用SVN, 开发个人项目时会使用GitHub Desktop, 笔者基于这一年里的git使用体会为有需要的同学们提供一些建议.
• 对笔者而言, SVN更像是一个文件共享工具, 整个团队, 包括产品原型, UI切图和代码等等的共享工具. git更适合于单纯代码方面的管理, 包括个人的代码开发管理和几个人之间的团队协作.
• git工具的使用很简单, 因为平常开发用得上的语法很少, 不过对于完全不了解的同学, 初次使用还是会觉得很陌生.

• 首先git工具是用来做代码管理和协作开发的. 你可以把你的开发代码放到远程的GitHub仓库里(GitHub的私有仓库是需要付费的, 相对的公开仓库则免费, 如果你不介意把代码共享给大家). 每次到了一定的开发阶段就把自己的新代码提交到远端的仓库(比如做一天的开发任务之后提交, 又比如做一段有影响的代码之前提交, 这个就看个人的判断了). 这个功能点上可以理解成云储存功能.
• git可以建立许多的分支, 每个分支下开发不同的功能, 或者是不同的人开发不同的分支. 不同的分支之间可以灵活切换, 合并. 分支也可以打上tag(标签)或者回滚, 总之我目前需要的功能他都有了. 这个功能点上其实和SVN是类似的.

关于日常 git 使用.

• 使用git前需要在本地初始化git, 即git init. 然后需要设置与GitHub仓库的连接, 有HTTPS和SSL两种方式, 这方面请参考其他文章.
• 1 假设已经存着远端仓库，打开终端terminal使用clone命令拉取远端仓库. 输入下方命令, 按照提示输入密码, 选择文件夹等. HTTPS 和 SSH 地址在GitHub 项目里面的绿色 Clone or download 按钮.
  git clone 项目地址(可以使用 HTTPS 或者 SSH 连接方式)
• 2 接下来是主要讲的日常操作. 当你完成了一个功能或者一天的工作需要提交的时候. 打开 terminal, 进入项目文件夹并输入下面的命令.
  git add . //把所有修改的文件加入追踪库,当然你也可以单独选择部分文件
git commit -m "注释" //提交到本地并注释
git push origin issue1 //提交到远端, issue1 是远端分支名
  这三句可能是日常中用到的最多的语句, 添加 - 提交.
• 3 如果你在不同的分支开发, 或者合并其他的分支时,就需要切换分支. 例如从 issue1分支切换到 issue2 分支.
  git checkout issue2 //切换到 issue2 分支
• 4 如果多人开发, 需要合并他人的分支的时候(比如我本地的 issue2 需要合并远端的 issue3 ). 我的做法是先新建一个和远端需要合并的分支名字相同的分支(这个新建的分支是以本地的 issue2 为基础新建的, 所以合并前是和 issue2 一模一样的, 相当于复制了 issue2), 然后拉取远端分支和新建的分支合并, 解决完冲突之后再合并到本地分支当中.
  git branch -a //查看所以的分支, 包括本地分支和远端分支
git checkout branch -b issue3 //以当前分支为基础新建名为 issue3 的分支并切换到 issue3, 这里是以 issue2 为基础新建 issue3
git pull origin issue3 //拉取远端的 issue3 分支和本地的 issue3 分支进行合并, 这时可能会提示有冲突, 有冲突时需要解决冲突
git add . //解决完 issue3 的冲突之后再提交到本地
git commit -m "注释" //需要先 commit 之后才可以切换分支
git checkout issue2 //切换到 issue2 分支
git merge issue3 // 把解决完冲突的 issue3 分支合并到当前分支 issue2
  这时候的 issue2 就已经是合并完线上的最新的代码了, 接下来在按照正常的程序 push 上去就行了. 合并时也可以先 fetch 再 merge , 就是先把远端的拉下来不合并, 再通过 merge 命令进行合并. 上边的 pull 其实是 fetch 和 merge 的集合, 拉取远端并直接合并.

关于协同开发.
协同开发最难的是代码库的管理和代码的合并. 我通常是这么做的:

• master 分支, master 分支是主分支, 每个上线版本都会合并到 master 分支上, 并打上 tag. master 分支仅由负责人进行管理.
• develop 分支, 由 master 分支切出来的 develop 分支是开发的主分支, 每个开发人员完成自己的任务之后都会拉取 develop 分支进行合并, 解决冲突之后再提交到 develop 分支上.
• 个人分支, 比如我叫 ken, 我就从 develop 分支上切出一个名为 ken 的分支作为我个人的主分支.
• issue分支, 用来管理单独的功能代码, 一般采用 issueX 的命名, issue 和 GitHub 库的 issue 对应. 比如我需要 code 网络层的代码, 我就在 GitHub 仓库建立一个 issue4, 然后本地以 ken 分支为基础建立一个 issue4 分支.

我的习惯是会频繁的更新个人分支, 在 issue 分支的小阶段完成后或者大改之前会把 issue 分支合并到 ken 分支. 等 issue 稳定之后会合并到 ken 分支,再合并到 develop 分支. 以此保证每个功能, 每个开发人员代码的独立, 以及 develop 分支的稳定.

还有一点就是每个人尽量只改动自己的部分, 需要修改其他人的部分之前如果有可能最好先沟通, 特别是 xib 以及 storyboard. 这样可以减少90%以上的冲突, 特别是难以用冲突工具解决的冲突.