Git与GitHub的区别
(2023.01.03 Tues)
Git是版本控制软件，用于跟踪文件的变化和多人协同修改这些文件(coordinating work on those files among multiple people)。主要用于软件开发中的源码管理，由Linus创建用于Linux内核开发。
与Git不同，GitHub是git仓库服务(git repository hosting service)，为git提供所有类型的代码管理。Github用于上传git仓库。
Git设计
(2022.08.23 Tues)
- Git版本管理的基础，是对不同版本的文件进行逐行对比(line diff)，并将新旧版本的差异作为文件的更新。通过
git add将修改添加到临时空间的对应文件，每个修改文件都会有对应的行对比的增量不定；再通过git commit从暂存区中将增量不定合并到本地仓库就得到了一个commit。 - 对于每个新生成的commit，对有对应的commit ID。生成commit ID的方法：通常在提交（commit）时，会生成一个SHA-1 Hash值作为commit ID。每个commit ID有40位十六进制数字，就是对那次commit在Git仓库中存储的内容和头信息（Header）的一个校验和(checksum)。Git使用了SHA-1并非是为了安全性，而是为了数据的完整性，即可以保证，在很多年后，重新checkout某个commit时，一定是它多年前的当时的状态，完全一摸一样，完全值得信任。
- 按时间线依次排列的一组提交记录形成一个branch，比如默认master分支即为一个branch，也可以根据某种需要创建分支。
- tag是某个关键commit的标签，比如发布1.0版本时的那次提交被专门打了个标签v1.0，tag标签就是一个别名，便于记忆和使用。
基于上面的介绍，引出merge的过程。
从远程的origin/master branch合并到本地master branch。项目从A版本出开始分叉，分别提交了BCD和EFG两组commit。合并时将D与A的差别和G与A的diff都放入工作区。若有冲突则可以提交一个版本H，完成两个分支的合并。
代码的H版本，根据一个公式简单计算出，即。
代码在远程与本地
本地与远程仓库中的代码做交互，还需要经过本地的仓库，如图所示是本地workspace与远程仓库交互的基本流程
(2023.01.03 Tues 加入同名部分和常用命令)
在本地，workspace也被称为working tree，index/tmp space也被称为staging area。workspace即工作台，是当前所有的文件，但这些文件并为被git跟踪(tracked)，除非使用
git add xxx命令将特定的文件加入到git的staging area。Staging area介于workspce和local repo之间，其中的文件即被git跟踪的文件，通过git commit命令将其中的文件加入到local repo。除了图上所示的部分，还有一个暂存区stash，后面会介绍。
一些常用命令：
git log
git status
git diff
从上面的illustration可以看到，本地与远程git沟通时，会在本地保存代码仓库(repository)。初始化和clone这些操作都是在本地仓库中完成。
本地repository保存在项目根目录下的.git文件夹中，每个repo中至少有一个master branch，还可能有多个其他branch。
在workspace(也就是当前工作环境中)，可以通过checkout命令切换本地repo中的不同branch，每个branch是一份完整源码。
在workspace中对文件的修改/新增需要推送到远端服务器，需要
- 先将修改加入到index或临时空间中，使用
add命令 - 从临时空间提交到本地repo中，使用
commit命令 - 从本地repo
push到远程代码仓库中
其中的临时空间或index也保存在.git目录中。
暂存区stash
(2023.01.03 Tues)
考虑一种场景，当我在project-a的branch-a中做开发时，同事有一个紧急需求需要修改branch-b的代码。此时需要保存branch-a的代码并切换branch。此时git返回信息："Your local changes to the following files would be overwritten by checkout … Please commit your changes or stash them before you switch branches."
此时的可行解决方案：
- 将
branch-a中的代码commit到staging area，并切换到branch-b，等编辑完成在checkout回到branch-a，并使用命令git reset HEAD^找回之前的位置 - 手动保存未被tracked的代码，即未通过
git commit添加到staging area的代码
一个更好的方案是代码放在暂存区stash。Git暂存区保存未提交到staging area的代码修改，之后可切换分支等其他Git操作。之后可重新应用(reapply)放在暂存区的代码。暂存区保存在本地并且不会被git push推送到remote repo。
暂存区的操作指令参考Git命令一文。
对远程仓库的操作
-
git remote：对远程仓库操作，可使用命令包括，查看远程仓库版本-v，显示远程仓库信息show，将本地仓库添加为远程仓库add [shortname] [url]，删除远程仓库rm rep_name，重命名远程仓库rename old_name new_name -
git fetch：从远程仓库下载对象等信息到本地仓库 -
git merge：合并多个开发历史记录 -
git pull：git fetch+git merge，从远程仓库下载并合并到本地仓库的当前分支 -
git clone：克隆一个远程仓库到本地的目录下
(2023.01.04 Wed)
包括暂存区在内，git本地的组织如下图所示
Git Workflow
(2022.09.25 Sun)
团队项目中如果不同成员同时向远程origin/master分支频繁提交代码，可能会导致诸多冲突合并的情况发生，同时git log提交记录中多个开发者或多个代码模块的commit是交错排列在同一条时间线上，跟踪代码变得困难。
这里介绍团队合作中的Git workflow，两种模式分别为分之合并和fork+pull request。
分支合并
保证不同的开发者或不同功能模块在时间线上呈现为独立的分支线段，在关键节点处进行分支合并。分支合并的典型工作流如下：
- 克隆最新的代码到本地存储
- 为当前工作/模块/feature创建一个新分支，该分支只负责单一功能模块或代码模块的版本控制
- 在新建分支上完成模块的开发工作
- 将该分支合并到origin/master分支
特别注意的是默认的合并方式为"快进式合并"（fast-farward merge），会将分支里commit合并到主分支里，合并成一条时间线，与我们期望的呈现为一段独立的分支线段不符，因此合并时需要使用--no-ff参数关闭"快进式合并"（fast-farward merge）。
操作方法：
1 clone项目后，创建新分支
git checkout -b <new_branch>
该命令用于在当前分支上创建一个新的分支<new_branch>。用git branch命令查看当前所处的branch。
2 用如下指令切换到新的branch。
git checkout <new_branch>
* master
mybranch
返回结果中名字带*的是当前branch。
3 在新分支中完成开发工作
git add FILES
git commit -m "commit log"
4 在新分支完成开发工作之后，在从remote更新分支后，可将其合并到master分支。如果创建新分支之后master分支有更新过，合并过程可能会因为有冲突(都修改了同一位置)而失败，这时新分支的代码已经合并到了当前工作区，只要在当前工作区里先解决冲突，然后提交到仓库(git add和git commit -m)即可完成合并。
合并时依次执行如下命令
git checkout master
git pull
git merge --no-ff <new_branch>
git push
merge命令中，如果未指定--no-ff，则默认使用fast-forward merge，新分支与master分支会合并到一条时间线中，图示如下
如果要保留新分支为一段独立的分支线段，则需要使用
--no-ff参数关闭"快进式合并"（fast-farward merge），Git命令如下：
git merge --no-ff <new_branch>
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。合并后示意图
这样在Git分支网络图中该工作有一段明确的分叉合并路径，如果整个团队每一项工作都参照这个工作流程，那么最终Git分支网络图中就会留下清晰的项目演进成长路径。
Fork-Pull Request
分支合并模式适合在紧密合作的开发团队中使用，而对于开源项目来说，该模式会导致混乱。Github提供了Fork+Pull Request的协作流程，想修改别人仓库的bug或贡献代码，这是建议流程。流程如下：
- 拷贝代码仓库，即fork他人仓库
- 在fork后的仓库中做项目修改更新
- 在fork后的仓库中发起pull request
- 原仓库作者review pull request，没问题则merge到原仓库中
Git典型Workflow (参考本文的Git Workflow)
(2022.01.09 Sun)
开发遵循Git工作流，使得Continuous Integration/Continuous Development(CI/CD)成为可能，也提升了CI/CD的效率。
commit changes这一步需要关注的问题是每次commit只添加一个独立、完整的修改，这样可以保证在需要revert(恢复)代码时，仅仅只只需要针对有问题的commit恢复，而不必做多余无效的工作。比如一个commit中包含了变量名修改和添加测试。如果后续发现变量名修改步骤出现问题，就不得不revert变量名修改和测试的两个内容。但如果变量名修改和测试是在独立的两次commit中，仅需要针对每个独立的问题，针对响应的commit做出修改。
create PR，即创建Pull Request，创建一个需求，目的在于pull提出的修改并merge到master branch里面。
merge到master branch之后，就可以删除创建的branch。
注意到deploy to prod发生在merge to master之前。在生产环境中部署的项目可能遇到各种技术问题和风险，可能需要回滚(rollback)。将deploy设置在merge之前可提高CI效率。
Reference
1 五⼤场景玩转 Git，只要这一篇就够了！独行学，微信公众号
