Git 使用分享

发表于 | 分类于

Git 几个重要的概念

  • 本地仓库
    Git 中大部分都是针对本地仓库的操作，完全不用担心污染远程仓库，比如 git add ，git commit ，git reset，checkout 等等。
  • 远程仓库
    服务端的代码仓库，用于多人协作开发。。。每个开发人员的本地仓库都是一份完整的远程仓库备份。
1
2
$ git push  // 推送至远程
$ git pull  // 从远程拉取

  • 工作区
    个人电脑中代码所在目录（除版本库之外的内容），比如我们android的项目在我电脑里的工作区就是 android-pay项目。

  • 暂存区
    stage 或者 index，在 .git 目录下，有一个 index 文件，它是一个包含文件索引的目录树，记录了文件名，文件的状态信息（时间戳，文件长度等）。文件的内容并不存储其中，而是保存在Git对象库（.git/objects）中，文件索引建立了文件和对象库中对象实体之间的对应。
    如果当前仓库，有文件更新，并且使用git add命令，那么这些更新就会出现在暂存区中。

  • 版本库
    执行 git init 命令后，生成的.git 目录。

工作原理示意图

屏幕快照 2017-06-14 17.21.06.png-159.7kB

为什么使用Git？

  • Git为分布式，SVN为集中式
    最核心的区别，Git几乎所有操作都可以脱离网络，SVN对网络依赖性比较强。

  • commit 更有意义
    随时随地，commit。。。区分功能的提交，保护临时开发成果，还不用担心影响到别人

  • 恢复版本
    Git版本库，记录了所有的提交历史，找到commit id就 可以一些文件恢复到上次改动之前的版本（甚至整个项目恢复到之前的版本）。

  • 查看历史
    本地即可查看历史提交，历史版本等Log。

  • 备份
    当然出现问题的概率很小，至少 Git 在每个开发人员电脑都做了一份备份。

  • 分支管理
    git clone 命令是 clone 整个完整的代码录，git branch -r 命令可以查看到项目所有的分支，checkout 移动指针切换分支。
    SVN 的 checkout 分支会在你的本地建立一个新目录。

  • Code Review
    代码合并前申请merge request，code review 更直观。
    Git 鼓励小功能也分支，简单快速么，合并分支需要 code review ，更利于我们代码质量的提高。

  • 开发中断，应对方便
    开发过程中必须切换分支，当前工作区修改处理方便。

  • 顺应潮流，拥抱变化

个人最大的感触是 SVN 慢，Git 快。Git对于临时开发成果的保护更好，更方便。
但是 Git 操作更繁琐一些，需要一定的学习成本。我们当初选择Git最大的原因是 Code Review。

SVN 迁移 Git 流程

  1. 项目管理员初始化版本库
    $ git init
  2. 创建远程仓库，本地生成 SSH key ，设置 SSK key。
    $ ssh-keygen -t rsa -C "youremail@example.com"
  3. 关联本地仓库和远程仓库。
    $ git remote add origin <仓库地址>
  4. 提交代码，推送至远程仓库
    $ git add <file> or git add .
    $ git commit -m <description>
    $ git push -u origin <branch name>
  5. 其余小伙伴 clone 仓库，创建关联分支，一起愉快的开发。
    $ git checkout -b <branch name>
    $ git branch –set-upstream-to=<repository>/<branch name>
    or
    $ git checkout -b <branch name> origin/<remote branch name>

代码管理策略

git flow推荐工作流

  • 主要分支
    master: 永远处在即将发布(production-ready)状态
    develop: 最新的开发状态

  • 辅助分支
    feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop
    release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master
    hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop

Android 团队

  • 常设分支
    master：即将发布出去的版本，可以理解为测试所用版本，QA测试Bug在该分支修改。发布新版本时在该分支打tag发布。
    dev：开发分支，小伙伴的feature分支都从该分支 chekcout ，feature分支 Demo 前合并到该分支（1.code review 2.检测CI是否正常），Demo通过后合并至master（Demo问题在dev修改，修改后code review通过合并），TAG标记。

  • 临时分支
    feature： 从 dev checkout，开发完成后，code view 合并至dev，进行Demo。
    Bug分支： 1. QA 提测 bug ， master checkout，修复后合并至master及dev 2. 线上热修复 TAG checkout，修复后合并至master 及 dev ，打TAG。

  • TAG： 发布版本，提测，热修复操作时打TAG进行标记。

移动团队另一种工作流

  • 常设分支
    master：开发及测试共用，发布在该分支打标签。

  • 临时分支
    feature： 从 master checkout，开发完成后Demo，Demo 通过后 code review 合并至 master。
    bug分支（热修复）： 从 tag checkout分支，修复以后合并至 master 及当前临时feature分支。打 tag 进行标记。

移动团队
Tips： 移动团队问题： dev 常设的必要性？

一些小Tip

常用 status 命令

多使用 git status 查看当前状态。

高质量的提交

  • 提交仅对应一个相关的改动
  • 完整的提交，不完整的请使用”Stash”
  • 提交前测试
  • 高质量的注释

养成一个频繁地进行提交的习惯。这样做将自然而然的让你避免一个很庞大的提交，并且使这些提交可以更好只对映一个相关的改动。

多使用分支

分支功能应该广泛地被运用在不同的开发主题中。比如添加新功能，修复错误，尝试新的想法等等。

遵循一个工作流程

选择什么样的开发流程要取决如下一些因素：项目开发的类型，部署模式和开发团队成员的个人习惯（可能是最重要的）。不管怎样，选择什么样的流程都需要得到所有开发成员的一致认可，并且一直遵循它。

合并主分支代码到feature分支

如果功能开发周期比较长，建议定期合dev分支代码到feature，减少冲突。

关联本地分支和远程分支

1
2
// 关联后pull 和 push 时可以偷个懒
$ git branch –set-upstream-to=<repository>/<branch name>

多SSH管理

  • 生成对应平台的 SSH key

  • 添加ssh私钥

    1
    2
    $ ssh-add ~/.ssh/id_rsa_github
    $ ssh-add ~/.ssh/id_rsa_gitlab

  • 创建修改config文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # gitlab
        Host gitlab.jinhui365.cn
        HostName gitlab.jinhui365.cn  
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_gitlab
        User gitlab username
    # github
        Host github.com
        HostName github.com
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_github
        User github username

  • 设置局部用户名和邮箱

    1
    2
    git config user.name "yourname"  
    git config user.email "youremail"

临时存储更改

开发过程中，由于某些原因需要切换分支，中断开发。。。需要把当前的工作区清理出来.

1
2
3
4
5
6
7
8
9
10
11
12
13
// 储存工作现场
$ git stash     
// 查看 stash 列表
$ git stash list
// 恢复工作现场 
$ git stash apply
$ git satsh apply stash@{0} 
// 删除工作现场
$ git stash drop
$ git satsh drop stash@{0}
// 恢复，并删除 stash 
$ git stash pop 
$ git satsh pop stash@{0}

Tip：临时存储时机：1， 切换分支之前 2，pull 之前 3，合并分支之前

author @ygwang