GIT常用命令及常见问题解决方法-协作篇

功能驱动

git 主要有三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。

它指的是，完成开发后，该分支就合并到主分支，然后被删除。

Git flow

最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。

它最主要的特点有两个

1.项目存在两个长期分支

master 主分支

 

develop 开发分支

 

//前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版，最不活跃的；后者用于日常开发，存放最新的开发版。

2.存在三种短期分支

功能分支（feature branch）

补丁分支（hotfix branch）

预发分支（release branch）

 

// 缺点： 部门开发中通常要不就一条master走到底，要不就是master+develop，其实基本满足需要了。多了徒增复杂度，维护起来很麻烦

Github flow （推荐）

Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。

它只有一个长期分支，就是master，因此用起来非常简单。

Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。

假设有1个github 地址 https://github.com/976500133/FETopic.git

1.克隆仓库 Repository 地址

git clone  https://github.com/976500133/FETopic.git

2.首先切换到devlop分支 (devlop 也可以叫其他的， 比如deploy 等)

git checkout -b devlop ( 及其重要：一定要确保 devlop是 基于 master 新建的， 也就是在master 的分支上运行  )

3.分出一个功能性分支

git checkout -b feature-user-profile

4.如果进行了一顿猛如虎的代码修改

5.测试没问题，提交更改

git add .   // feature-user-profile 

git commit -m "add user-profile feature "

6.拉取最新代码（非必要）

git pull  (非必要，在push 不上去的时候 需要执行)

7.推送分支到远程

git push origin feature-user-profile

 

或者

git push --set-upstream origin feature-user-profile  //(只设置一次就行)

git push  //以后可以直接push

8.假设是master 为主分支,通知主分支合并feature-user-profile,

git rebase origin/master

 

//如果出现冲突 conflict , 解决完之后 执行

 

git add .

git rebase --continue //多次冲突的话需要多次执行命令 

 

//如果放弃的话， 使用如下命令

git rebase --abort

9.把rebase 过的代码推送到远程

git push -f origin feature-user-profile

10.直接master 合并 feature-user-profile 就是直线了~！！赞

git checkout master

git pull 

git merge origin/feature-user-profile

Merge节点

Git merge 有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另一种是"非直进式合并"（none fast-forword），会生成单独节点。

前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用--no-ff参数）。只要发生合并，就要有一个单独的合并节点。

部分非完全精准的总结

git merge | 直接合并某个分支或节点。用于2个不同分支直接的代码合并

git cherry-pick 摘取合并某次提交的信息 , 比如我某次提交就叫了一句注释，就会合并进来这句注释

git rebase 时间基线会修改，修改时间线,让线看起来笔直的