Git Using

Git一般划分为3个区域，working directory 为当前工作区、stage/index 为暂存区（git add 后的代码就会存储在这部分）、repository 则记录提交的历史（git comment 后的代码会存在这里）。3个区域关系如下图所示。

Git Reset有三种模式，soft,mixed,hard，具体的使用方法如下面这张图：

1. reset --hard：重置 stage 区和工作目录。

reset --hard 会在重置 HEAD 和 branch 的同时，重置 stage 区和工作目录里的内容。当你在 reset 后面加了 --hard 参数时，你的 stage 区和工作目录里的内容会被完全重置为和HEAD的新位置相同的内容。（三个区域全变且一致）效果看起来等同于清空暂存区和工作区。

2. reset --soft：保留工作目录，并把重置 HEAD 所带来的新的差异放进暂存区。 

reset --soft 会在重置 HEAD 和 branch 时，保留工作目录和暂存区中的内容，并把重置 HEAD 所带来的新的差异放进暂存区。（working directory 内容不变，repository与目标节点一致，stage/index 新增 repository 在两个版本的差异）
 

3.reset 不加参数(mixed)：保留工作目录，并清空暂存区。
reset 如果不加参数，那么默认使用 --mixed 参数。它的行为是：保留工作目录，并且清空暂存区。也就是说，工作目录的修改、暂存区的内容以及由 reset 所导致的新的文件差异，都会被放进工作目录。简而言之，就是「把所有差异都混合（mixed）放在工作目录中」。
Git - 重置揭密 (git-scm.com)

Git 如何撤销 Git 中的 git add

git-cherry-pick - Apply the changes introduced by some existing commits.

git cherry-pick <commit-id>  当执行完 cherry-pick 之后，将会自动生成一个新的 commit 进行提交，也就是会有一个新的 commit ID。

git cherry-pick -x <commit_id>  增加 -x 参数，表示保留原提交的作者信息进行提交。

When recording the commit, append a line that says "(cherry picked from commit …​)" to the original commit message in order to indicate which commit this change was cherry-picked from. This is done only for cherry picks without conflicts. Do not use this option if you are cherry-picking from your private branch because the information is useless to the recipient. If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.

git cherry_pick <start-commit-id>…<end-commit-id> 批量 cherry-pick  (1.7.2)，就是可以一次将一个连续的时间序列内的 commit ，设定一个开始和结束的 commit ，进行 cherry-pick 操作。它的范围就是 start-commit-id 到 end-commit-id 之间所有的 commit，但是它这是一个 (左开，右闭] 的区间，也就是说，它将不会包含 start-commit-id 的 commit。

如果想要包含 start-commit-id 的话，就需要使用 ^ 标记一下，就会变成一个 [左闭，右闭] 的区间，具体命令如下。git cherry-pick <start-commit-id>^...<end-commit-id>

如果顺利的话，就可以正常提交了。如果遇到冲突，使用 git diff 解决冲突即可，工作中，不推荐手工解决冲突，最好还是使用一些 diff 工具来处理，毕竟手工处理容易出错。

注意事项：无论是对单个 commit 进行 cherry-pick ，还是批量处理，注意一定要根据时间线，依照 commit 的先后顺序来处理，否者会有意想不到的问题。

git stash 用法详解 (baidu.com)

git stash 命令用于保存当前工作目录的临时状态，包括暂存区和已修改但未暂存的文件。它会将这些修改保存在一个临时区域（即“堆栈”）中，让你能够回到一个干净的工作目录，可以进行其他操作。等到你完成其他任务后，可以再回到之前的状态，继续之前的开发。

使用场景：

1. 切换分支： 当你正在开发一个功能或修复一个 bug，但需要切换到另一个分支来处理其他任务时，使用 git stash 可以将当前的修改保存起来。这样你可以切换到其他分支并开始另一个任务，而无需提交或放弃你当前的修改。

2. 合并代码： 在进行代码合并操作之前，你可能需要切换到目标分支并更新代码。使用 git stash 可以保存当前分支的修改，然后切换到目标分支并执行更新操作。完成后，你可以切换回原分支，并使用 git stash pop 来恢复之前的修改。

3. 临时修复问题： 如果你遇到一个紧急的问题，需要快速切换到其他分支进行修复，但又不想丢失当前的修改，可以使用 git stash 将修改保存起来。然后你可以切换到修复分支，并在修复完成后再回到原分支恢复之前的修改。

4. 多任务处理： 在开发过程中，你可能会同时处理多个任务或功能。当你想切换到另一个任务时，可以使用 git stash 将当前任务的修改保存起来，然后切换到另一个任务并开始工作。完成后，你可以回到之前的任务并使用 git stash pop 来恢复修改。

5. 代码审查： 在进行代码审查时，你可能需要将修改保存起来，以便在审查过程中进行对比和讨论。使用 git stash 可以暂时保存你的修改，并切换到源代码分支进行对比和审查。

请记住，git stash 是一种临时保存修改的方法，并不应该被滥用。它主要适用于短期的临时任务和临时保存修改的情况。

注意在应用某个特定的 stash 恢复修改内容时，最好确保你当前的工作目录是干净的（没有未提交的修改），这样可以避免一些潜在的冲突和问题。另外，git stash 是一个非常有用的命令，但不应该滥用它。如果可能，最好尽量完成当前的修改并提交它们，而不是经常性地使用 stash 来处理分支切换。

git pull --rebase 的作用是什么，它与 git pull 有什么区别？
git pull = git fetch + git merge FETCH_HEAD 
git pull --rebase =  git fetch + git rebase FETCH_HEAD 

二者的区别是，在 fetch 之后的操作不同，merge 与 rebase 的不同。

假设当前 master 的提交如下：

工作临时分支 tmp

merge 的结果是新增了 commit cid6：

rebase 后没有产生新的节点，使用 rebase 的 git 演进路线(提交树)是一直向前的，这样在版本回退时也很容易，用 merge 的 git 路线是跳跃的。当合并代码有冲突时，需要手动修改冲突内容后，add，commit, push. 而 rebase 操作的话，会中断 rebase，同时会提示去解决冲突。解决冲突后, 再执行 git rebase –continue 继续操作，再 push。

想要更好的提交树，建议使用 rebase 操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点。不过也有些项目，不建议使用 rebase,  一般使用 merge，或者看公司与项目的规定。

git pull 问题的解释和解决方案

【iOS开发笔记】git pull问题的解释和解决方案 - 简书

git config --global --add pull.rebase false

git config pull.rebase false 的作用是设置 Git 在执行 git pull 命令时默认使用 merge 而不是 rebase。 git pull 命令是将远程分支的更新合并到本地分支，如果本地分支有更新，则会自动执行合并操作。默认情况下，git pull 命令会使用 rebase 的方式来合并分支。使用 rebase 的好处是可以保持提交历史的线性，避免了 merge 产生的分支合并记录。但是，如果在多人协作的项目中使用 rebase，可能会破坏提交历史，导致代码冲突，因此需要谨慎使用。 通过设置 git config pull.rebase false，Git 将默认使用 merge 的方式来合并分支，从而避免了 rebase 带来的潜在问题。 需要注意的是，如果在执行 git pull 命令时指定了 --rebase 选项，则 Git 会优先使用 rebase 的方式来合并分支，而不受 git config pull.rebase 的设置影响。因此，如果需要强制使用 merge 的方式来合并分支，可以在执行 git pull 命令时添加 --no-rebase 选项。

不同公司，不同情况有不同使用场景，不过大部分情况推荐如下：

1. 拉公共分支最新代码——rebase，也就是 git pull -r 或 git pull --rebase。这样的好处很明显，提交记录会比较简洁。但有个缺点就是 rebase 以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛，所以看个人需求了。总体来说，即使是单机也不建议使用。
2. 往公共分支上合代码——merge。如果使用 rebase，那么其他开发人员想看主分支的历史，就不是原来的历史了，历史已经被你篡改了。举个例子解释下，比如张三和李四从共同的节点拉出来开发，张三先开发完提交了两次然后 merge 上去了，李四后来开发完如果 rebase上去（注意，李四需要切换到自己本地的主分支，假设先 pull 了张三的最新改动下来，然后执行<git rebase 李四的开发分支>，然后再 git push 到远端），则李四的新提交变成了张三的新提交的新基底，本来李四的提交是最新的，结果最新的提交显示反而是张三的，就乱套了，以后有问题就不好追溯了。
3. 正因如此，大部分公司其实会禁用 rebase，不管是拉代码还是 push 代码统一都使用merge，虽然会多出无意义的一条提交记录 “Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序。

如果碰到公司禁用 rebase 这种情况 ，一般提交操作步骤如下：

1. 切换到 master 分支， git pull 一下，拉下主分支最新的 HEAD。
2. 切换到开发分支 xxxx， git merge master， 解决冲突，然后 commit 。
3. push 开发分支到 remote 并请求 Review ： git push origin HEAD:xxxx
4. Review 后由 jekins merge 到 master 主分支。