Git和SVN有什么区别？
| Git | SVN |
|---|---|
| 1. Git是一个分布式的版本控制工具 | 1. SVN 是集中版本控制工具 |
| 2.它属于第3代版本控制工具 | 2.它属于第2代版本控制工具 |
| 3.客户端可以在其本地系统上克隆整个存储库 | 3.版本历史记录存储在服务器端存储库中 |
| 4.即使离线也可以提交 | 4.只允许在线提交 |
| 5.Push/pull 操作更快 | 5.Push/pull 操作较慢 |
| 6.工程可以用 commit 自动共享 | 6.没有任何东西自动共享 |
如何判断分支是否已合并为master？
git branch –merged 它列出了已合并到当前分支的分支。
git branch –no-merged 它列出了尚未合并的分支。
描述一下你所使用的分支策略？
- 功能分支（Feature branching）
要素分支模型将特定要素的所有更改保留在分支内。当通过自动化测试对功能进行全面测试和验证时，该分支将合并到主服务器中。
- 任务分支（Task branching）
在此模型中，每个任务都在其自己的分支上实现，任务键包含在分支名称中。很容易看出哪个代码实现了哪个任务，只需在分支名称中查找任务键。
- 发布分支（Release branching）
一旦开发分支获得了足够的发布功能，你就可以克隆该分支来形成发布分支。创建该分支将会启动下一个发布周期，所以在此之后不能再添加任何新功能，只有错误修复，文档生成和其他面向发布的任务应该包含在此分支中。一旦准备好发布，该版本将合并到主服务器并标记版本号。此外，它还应该再将自发布以来已经取得的进展合并回开发分支。
如何在Git中创建存储库？
要创建存储库，先为项目创建一个目录（如果该目录不存在），然后运行命令 git init。通过运行此命令，将在项目的目录中创建 .git 目录。
git 如何解决代码冲突？
git stash
git pull
git stash pop
操作就是把自己修改的代码隐藏，然后把远程仓库的代码拉下来，然后把自己隐藏的修改的代码释放出来，让 git 自动合并。接着找 <<<<<<<, 哪里冲突哪里改。
如果要代码库的文件完全覆盖本地版本?
场景就是合作的远程仓库上，别人做了一些改动，我在本地也做了一些 commit , 然后把别人的 commit 拉下来，再把我的更改添加上去。接着找 <<<<<<<, 哪里冲突哪里改。 这个时候，先检查一下我的本地仓库与合作的远程仓库的最近的一个共同 commit id.
git reset commit id
git stash
git pull
git stash pop
git reset commit id 的作用是取消暂存文件。将 HEAD 的指针指向 commit id，修改了暂存区域 Staging Area 和版本库 Commit History，工作区沙盒 Working Directory 保持原样。
git rebase, git merge 的区别?
git rebase 和 git merge 都可以用于合并分支，从 feature 分支上，取得新的提交 commits , 然后运用到 master 分支上（当然运用到其他分支上也行）。
merge 是合并，rebase 是变基.
git merge 会把公共分支和当前的commit合并在一起，形成一个新的commit提交。
git rebase 会把你当前分支的commit放到公共分支的最后面，所以叫变基。
举例：如果你从master拉个feature分支，然后提交几个commit，这个时候刚好有人把他开发的东西合并到master,这个时候master就比你拉分支的时候多了几个commit，如果这个时候你在feature上rebase master的话，就会把你当前的几个commit，放在那个人commit的后面。
GitFlow 基本流程和你的理解?
| 名称 | 说明 |
|---|---|
| master | - 主分支，保持与线上内容一致，任何变化都要触发线上部署 - 只接受hotfix和release的PR |
| develop | - 当前最新开发的分支 主开发分支，包含确定即将发布的代码 - 只接受feature的PR，只能合并到release；release和master有变动时要及时同步变化 |
| feature | - 新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理，以避免一些后面不必要的代码冲突，提测前的分支 - 只能从develop切，只能合并到develop |
| release | 测试验收、灰度用的分支，发布分支，发布时候用的分支，一般测试时候发现的 bug 在这个分支进行修复 |
| hotfix | - hotfix 分支，紧急修 bug 的时候用 --- 只能从master切，只能合并到master，保证master和release分支代码一样 |
项目迭代通常是：开发=》提测=》Debug=》上线，这样的流程，中间会穿插进高优需求和hotfix。
- 需要一个分支与生产环境完全对应，以随时处理hotfix（紧急bu g）的情况，使用master分支
- 需要一个分支聚合日常开发的所有内容，保持最新的代码，以方便所有协作者同步代码，推荐develop分支
- 线上出现紧急BUG，需要马上修复并上线，不适合直接在master分支上操作，需要一个临时分支，推荐hotfix
- 每个人的日常开发分支，用到多个分支，以feature为单位，用完即删
- 提测后的debug阶段，建议使用bugfix分支与feature分支进行区分，推荐使用bugfix分支
- Debug后处于上线ready的状态下，需要一个专门上线的分支，推荐使用release分支
