git stash处理hot(bug)-fix与cherry-pick

目录

hot-fix

介绍

git stash注意点

常用git stash命令 

cherry-pick

冲突处理

---

hot-fix

介绍

        是什么：热修复。

        场景一：需要直接修改生产环境 prod 或发布分支 （release）上面的问题，我们就会提个 hot-fix 进行解决。

        从 pro 拉个临时分支，然后本地切换到临时分支上，进行修改，完了后合到 prod 即可。

       具体步骤：

                1. 在远程仓库的pro分支处，新建分支，可命名为 hot-fix630

                2.  切换到临时分支   git checkout -b origin/hot-fix630

                3. 进行修改，然后push到远端

        场景二：你在工作区已经修改了多个文件，突然需要修复 prod分支上的紧急bug。

        修复线上的问题有时候也叫 bug-fix：热更新 ,除了以上方法还有一个更不用额外拉分支的方法：git stash

         具体步骤：

        1. 使用 git stash 就可以将你当前未提交的代码推入到Git的栈中（把暂存区和工作区的改动保存起来），此时工作区间和上一次提交后的内容是完全一样的（干净的）；

        2. 切换到另一个分支去修改bug，完成后提交

        3. 使用 git stash apply 将以前一半的工作应用回来，然后接着开发。

        场景三：如果对多个文件做了修改,但是只想提交特定文件,或者想先暂时保存几个修改,测试其他文件的效果.

 
 git add --patch foo            //只将第一部分加入git管理 
 git stash save --keep-index    //将其余部分暂存起来
 edit/build/test first part
 git commit -m 'First part'    //提交全部的git管理中的代码
 git stash pop                  //继续进行存储代码的工作
# ... repeat above five steps until one commit remains ...
 edit/build/test remaining parts
 git commit foo -m 'Remaining parts'

git stash注意点

• 截至 2017 年，开始弃用 git stash save 命令， 代之以现有 git stash push 命令

• 默认情况下，git stash只会缓存Git 跟踪（添加到暂存区的修改 staged changes
  Git跟踪的但并未添加到暂存区的修改 unstaged changes ）的文件，可以通过添加参数改变默认设置：        

        -u:会将未跟踪的文件也缓存 （）

                 -a : 除了未加入管理的文件,被git忽略(ignore)的文件也会被缓存

• 创意性使用

        --keep-index(简写为-k): 只会存储为加入add的文件,同时还要将它们保留在索引中

        -p: 不会贮藏所有修改过的文件， 但会交互式地提示我们选择当前修改和HEAD提交diff部分 

• 参考链接

常用git stash命令 

（1）git stash push " message "  : 执行存储时，添加备注，方便查找，只有 git stash 也要可以的，但查找时不方便识别。

（2）git stash list  ：查看stash了哪些存储

（3）git stash show ：显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}

（4）git stash show -p : 显示第一个存储的改动，如果想显示其他存存储，命令：git stash show  stash@{$num}  -p ，比如第二个：git stash show  stash@{1}  -p

（5）git stash apply :应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1} 

（6）git stash pop ：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}

（7）git stash drop stash@{$num} ：丢弃stash@{$num}存储，从列表中删除这个存储

（8）git stash clear ：删除所有缓存的stash

cherry-pick

        是什么：捡樱桃

        通俗来讲就是，开发时，距离上次发版到 pro 已经在 dev 环境上新增了多个功能，提交了很多次（建议每次提交只设计一个功能）；现在需要把其中某个功能推到生产环境 pro。

         怎么办：选中其中的几次commit推到pro,假如某次提交涉及多个功能，要把多余功能的代码注释或者删除。

        注意：如果是多人开发同一个页面，原则上不能动其他人的代码！若他人也涉及到某些功能的提交，需要本人亲自相应处理。

       如果每次commit都很规范（只涉及单个功能）则可用一下 git 命令：

// 合并一次commit; -x 可省，保留的话则可保留原提交者commit信息。
git cherry-pick -x <commit id> 

// 合并多次commit; 闭区间
git cherry-pick <start-commit-id>^..<end-commit-id>

        若某次提交涉及多个功能，则只能手动把多余功能的代码注释或者删除。

冲突处理

        以上的过程，很有可能出现冲突，因为团队协作中你当前要提交的代码，可能与当前 pro 上面的某处代码不一样（别人上次提交的），你此时的提交就会出现冲突，那解决流程如下：

// 查看哪些文件出现冲突
git status  
// 找到冲突处，手动修改   
vim xxx.jsx   
// 将该文件添加到缓存区
git add xxx.jsx
// 提交 push
git commit -m 'fix: 修改冲突'
git push

        假如你从 dev 合并代码到 pro 出现冲突，需要在本地切换到 pro 分支 pull 当前 dev 的代码，然后解决冲突后再 push 到远端pro环境