rebase坑

feature 相对 origin/main 独有的那一串提交，如果origin/main 之前解决过冲突，拥有了那些本来是feature独有的提交但其实文件代码已经被解决冲突覆盖过了，这样造成feature 相对 origin/main 独有的那一串提交被忽略从而被覆盖代码

强行合并feature分支所有commit到main分支
git checkout main
git pull origin main
git checkout -b sync-feature-files
帮我列出feature分支这些commit涉及到的所有文件
然后执行git checkout feature -- path/to/file1 path/to/file2
把这些文件复制到sync-feature-files分支
git commit -m "Take feature versions of selected files"

上层

存储项目源码
记录源码版本

上层

• 记录更改历史变化

• 项目多人开发管理：
  1）项目多个成员【基于主世界线master分支，拉取各自的多世界线feature开发分支】，并行开发
  2）最后【部署的粒度是同一个项目 -> 每个人的代码不是最新可能造成覆盖 -> 需要收束到一个公共develop分支解决大家的代码冲突】-》公共develop分支包含了所有人同时正在开发的代码
  3）基于测试通过的版本【生成发布版本进行发布】
  4）【发布完成后】，将发布版本代码【合并回主世界线master分支】-》保证【新开发功能】从master拉取到最新代码 ！
  5）【发布完成后】，将发布版本代码【合并回多世界线feature开发分支】-》保证【正在开发】的各个feature分支更新最新代码！

本地仓库工作流

1）在本地目录初始化仓库
git init # 创建.git文件夹

2）查看git配置信息
查看所有配置项
git config --list
查看用户信息
git config user.name # 查看当前仓库配置的用户名
git config user.email # 查看当前仓库配置的邮箱
git config --global user.name # 查看全局配置的用户名
git config --global user.email # 查看全局配置的邮箱

2）设置本地仓库的用户信息
git config --add user.name myname # 用户名
git config --add user.email myemail # 邮箱
通过--global参数设置全局账号

3）添加文件到暂存区
git add *.md # 添加md格式的文件
git add -A # 添加所有没加到暂存区的文件
通过--edit参数在编辑框中选择部分代码添加到暂存区

4）提交暂存区文件到本地仓库区
git commit -m "related message"
使用--amend参数追加文件到上一次提交
通过--date参数指定提交的时间

5）忽略文件进入版本控制
新建.gitignore 文件

6）删除、修改文件
git rm
git mv

7）推送本地仓库数据到远程仓库

远程仓库工作流

1）Fork他人远程仓库（upstream）到个人远程仓库（origin）

2）克隆个人远程仓库到本地仓库
git clone http://url # 克隆仓库默认与远处仓库同名，可通过后接foldername自定义仓库名
git clone -b 分支名 url
默认远程仓库主机名为origin
通过-o参数指定远程仓库主机名

3）查看远程仓库
git remote # 查看远程仓库的主机名
通过-v参数查看远程仓库url
通过git push origin -d BranchName删除远程仓库上的分支

4）对于不是通过git clone克隆到本地的项目，需要【手动关联远程仓库跟踪】
git remote add remote-name remote-url
通过git branch -r -D origin/BranchName删除远程仓库分支跟踪
git branch --set-upstream-to=origin/<branch> master
设置本地分支master跟踪origin/<branch>远程分支

5）创建分支
git branch new-branch # 默认创建的分支是当前分支的镜像
通过git branch -d删除分支
通过git branch查看分支
通过git branch -r查看本地仓库中保存的远程仓库分支
根据远程仓库创建分支：git checkout -b template origin/template

6）切换分支
git checkout new-branch
通过-b参数创建并切换到新分支

7）更新所有远程分支到本地.git仓库区：【拉取远程新增分支 + 拉取远程旧分支的最新代码】
git fetch

8）更新远程分支到【本地项目代码工作区】
方法1：git merge 远程分支
前提是已经使用git fetch更新了远程分支的最新代码）

方法2（推荐）：【git pull】
本质上等价于【git fetch + git merge】，语法更简洁 ！

• 通过git pull --rebase从而变为了等价于【git fetch + git rebase】

git merge和git rebase的区别
想象一个场景，我们在本地的个人feature分支开发过程中，远程main分支发生了变化，而我们【没有及时的合并远程main分支变化】进行了本地的增量开发
当我们push个人feature分支时显然需要先合并远程的main分支
这时候有个问题是个人feature分支的commit时间线，与远程的main分支的【commit时间线产生了交错】
git merge的做法是【冗余生成一个合并commit】，这个commit有【两个父提交分别来自于：本地个人feature分支的最新commit + 远程mian分支的最新commit】，显然不能形成一条线性的commit时间线 ！！！
而git rebase的做法是假设我们及时的合并了远程main分支变化，再进行的本地的增量开发
即将：在远程mian分支的最新commit【之后】，【追加了】本地个人feature分支的【一系列commit】
从而形成一条线性干净的commit时间线 ！！！

具体到我们的idea中，右上角的update project图表点击后会出现弹出框让我们选择是【 pull merge还是pull rebase】
并且可以设置默认选项！

9）解决冲突
【保留个人代码 / 别人代码 / 合并后的新代码】
更新本地主分支的代码，修改开发分支代码不再冲突后，再合并到本地主分支

10）推送本地仓库数据到个人远程仓库
git push remote-name branch-name

11）登录个人github，新建Pull Request，将修改提交到他人远程仓库供他人审批

开发技巧

• rebase如何解决冲突
  首先我们要知道rebase的底层原理
  1）将feature分支的所有提交取消
  2）把这些提交临时保存下来，每个提交看作是一个patch补丁
  3）将最新的master分支数据更新到feature分支
  4）把上面保存的每一个patch补丁，依次应用到当前的feature分支，看是否会发生冲突？

具体到我们的idea中，一个patch补丁如果发生冲突会弹出一个三栏框
左边是我们feature分支的冲突代码，右边是master分支的冲突代码
需要我们在中间栏进行手动解决冲突
完成这个patch补丁造成的冲突后点击continue，继续解决下一个patch补丁造成的冲突 ！！！

• 如何进行回退操作
  回退是【针对当前分支】的回退，其他分支不受影响

1）暂存区文件级别的回退
git rm --cached your-file // 回退新增
git reset your-file // 回退修改

2）本地代码文件级别的回退（危险操作，无法撤销 ！）
git checkout your-file

3）【提交级别的回退】
通过revert回退（不推荐）
创建某次提交的逆操作并执行提交，缺点是为了回退额外生成了一次【逆提交】
git revert hash-code

【通过reset回退】
真正的让commit时间线进行时光回溯，不会产生额外的commit ！
【软回退】：取消最后一次提交，【保留本地代码不受影响】
git reset --soft HEAD^ // HEAD^代表上一次提交的版本
【硬回退】：删除最后一次提交，【同时回退本地代码】
git reset --hard HEAD^

• 当然也可以指定回退到具体版本git reset --hard xxx
  比如我们的rebase完成后想要进行回退，可以先找到rebase之前的版本号
  再进行硬回退到rebase之前的版本 ！

4）如何撤销远程push
首先对本地项目进行提交级别的回退，注意如果是软回退需要先将【冗余保留的本地代码stash冷冻起来】，保证本地代码的干净
然后执行push --force，这里添加forc参数是因为本地的版本落后于远端的版本，需要强制push

5）【冷冻代码】
当我们【编写的代码觉得有问题】，或者【与远程发生冲突时】，可以先把这些代码冷冻起来，从而【得到一个干净的代码工作区】，等到合适的时候再将其释放出来 ！
git stash # 冷冻代码，恢复到上次提交
git stash list # 查询冷冻环境列表
git stash pop # 解冻代码
git stash apply # 解冻代码（更安全），不会把存储删除，从而可以重复解冻 ！
git stash drop # 删除冷冻代码的存储

6）提交代码的同时， 再复制一份待提交的代码到本地
先提交push到远程
再在本地reset soft回退，得到新的待提交代码
最后通过idea的smart checkout 切换到新分支并保留待提交代码镜像

先提交push到远程
再在本地reset soft回退，得到新的待提交代码
再stash保存新的待提交代码
再pull远程把当前分支恢复
最后切到其他分支stash pop

7）修改提交历史
git rebase -i 起始历史版本（开区间）
"pick"，表示执行此次提交；
"reword"，表示执行此次提交，但要修改备注内容；
"edit"，表示可以修改此次提交，比如再追加文件或修改文件；
"squash"，表示把此次提交的内容合并到上次提交中，备注内容也合并到上次提交中；
"fixup"，和 "squash" 类似，但会丢弃掉此次备注内容；
"exec"，执行命令行下的命令；
"drop"，删除此次提交。

8）提交标签
commit 是细粒度的、面向程序员的，每写一个函数、每修正一个 bug，都可以提交一个 commit
tag 是【粗粒度】的、面向用户的，一般在【增加功能】时，才打一个 tag，即发布一个新的版本号
为一次commit打上tag标签

git tag tag-name # 给【最近一次提交打标签】
git tag tag-name a38862a5a860 # 给指定提交打标签
git tag # 查询所有标签
git tag -d your-tag # 删除标签
git push --tags # 把打的标签推送到远程仓库

查询仓库

0）.git目录中包含了本地仓库 + 远程仓库数据
1）工作区 = 本地仓库当前分支数据 + 未跟踪数据 + 已修改数据 + 暂存区数据
2）查看文件状态
git status -s # 查看简洁状态

untracked：未被跟踪的文件
modified：被修改过的文件
staged：已加入暂存区的文件
3）查看提交日志
git log # 查看本地仓库当前分支提交日志
git log branch-name # 查看本地仓库指定分支提交日志
git log remote-name/remote-branch # 查看远程仓库提交日志
通过---pretty=oneline参数查看简明信息
4）查看本地跟踪分支对应的远程分支
git branch -vv（两个v），就能够看到本地分支跟踪的远程分支。
5）查看代码修改时间
git blame your-file
6）搜索文件
git grep keyword # 搜索当前项目
git grep keyword file-name # 搜索指定文件
7）查看git操作记录
git reflog

配置多个账号SSH

1）创建私钥
ssh-keygen -t rsa -C "two@gmail.com"
不要一路回车，分别在第一个对话的时候输入重命名（id_rsa_one和id_rsa_two）

2）配置代理
ssh-agent bash # 打开代理
ssh-add ~/.ssh/id_rsa_two # 添加私钥

3）创建config文件（在.ssh目录下）
Host one.github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_one
User one

Host two.github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_two
User two

4）配置GitHub
两个账号打开“Account settings”--“SSH Keys”页面，然后点击“Add SSH Key”，添加公钥

5）测试链接
ssh -T git@one.github.com
ssh -T git@two.github.com

================= old

发布流程

• 原始
  持续发布型
  本地直接基于master分支开发，push到远程master

• github
  持续发布型
  【本地创建】临时开发分支【feature】进行开发，开发完成后push到远程
  远程对源master分支发起合并请求：【远程feature合并到master】-》【大家的代码收束到master分支解决冲突】

• git flow
  版本发布型
  【远程】创建【开发分支develop】
  本地创建临时开发分支feature进行开发，开发完成后push到远程
  远程对源develop分支发起合并请求：【远程feature合并到develop】-》【大家的代码收束到develop分支解决冲突】
  如果要发布版本，【基于develop创建远程【预发布（表示开发阶段已经完成即将发布）】分支release.X】-》【测试同学基于预发布分支release进行部署测试】
  如果测试没问题，将【远程预发布分支release合并到master，develop】
  基于【master分支做发布】

• gitlab
  1）持续发布型
  创建以下分支：
  永久分支包括开发分支master，准生产分支pre-production，生产分支production。
  临时分支分为功能分支Feature和修复分支Fix，在开发完成会被删除
  代码的变化，必须由”上游”向”下游”发展。Feature和Fix是master的”上游”，master是pre-production的上游，pre-production是production的”上游”
  要开发新的feature，这时就要【创建一个临时分支，开发完成把它合并到master】-》【大家的代码收束到develop分支解决冲突】
  确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production

2）版本发布型
每一个发布版本开发前，由发布负责人提前从master分支拉出一个版本分支，比如2-3-stable、2-4-stable等
开发者从master分支创建临时分支feature进行开发，开发完成后push到远程
开发者在远程对源stable分支发起合并请求
如果有问题，修改临时分支feature，重新对源stable分支发起合并请求
开发者在远程对源release分支发起合并请求
如果有问题，修改临时分支feature，重新对源release分支发起合并请求
至此发布完成：
由发布负责人将代码由release分支同步到master分支，创建tag
由发布负责人重新将master更新到其他正在开发的feature分支
由发布负责人重新将master更新到stable分支
由开发者将自己创建的临时分支feature删除

• rebase
  把当前分支的开始时间轴向后移动到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样
  git rebase new-branch
  操作默认自动提交到本地仓库
  分支提交前的修改会影响所有分支
  通过--squash参数合并到主干的上一次提交，此时合并后需要手动commit到本地仓库
  通过git cherry-pick hash-code合并分支中的某一次提交

  
  

• 其他方式
  1.9.9代码需要迁移到1.10.3发布
  开发分支仍然提交合并到1.9.9
  审核通过后从1.9.9拉取新分支1.10.3
  再将master合并到开发分支，开发分支提交合并到新分支1.10.3

9）打包修改、提交对象
git repack
从他人仓库fork项目到自己仓库，当自己的该仓库发生变化时，会自动打包对象生成pull request

数据库ddl修改

编写数据库修改的脚本，在项目初始化代码中执行脚本，以便使数据库修改和代码一起受版本控制