GIT

书籍：《Pro Git》

pic

版本控制

• 集中式：svn
• 分布式：git
• 本地

本地版本控制：在硬盘上保存补丁集，不能协同工作

集中化版本控制：实现协同工作，但是由于由中央服务器统一维护，存在丢失风险

分布式版本控制：把代码仓库完整镜像保存下来，包括完整的历史记录，去中心化

Local

工作区、缓存区、提交区

Remote

冲突

单分支冲突

单分支冲突场景：在单位提交了push iss1到dev分支，在家里没有pull iss1的情况下 进行了iss2的工作，当 push时会reject要求解决iss1 和iss2的冲突之后再push

多分支冲突

多分支冲突场景：

1. 开发某个网站。
2. 为实现某个新的用户需求issue，创建一个分支。
3. 在这个分支上开展工作。
   正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理：
   1. 切换到你的线上分支（main）。
   2. 为这个紧急任务新建一个分支hotfix，并在其中修复它。
   3. 在测试通过之后，切换回线上分支，然后合并这个修补分支(merge hotfix)，最后将改动推送到线上分支，删除hotfix分支(branch -d hotfix)。
4. 切换回你最初工作的分支issue上，继续工作。
5. 完成issue的开发工作，合并issue分支(merge issue 出现分支冲突)
6. 需要处理conflicts，然后git add, commit, push, branch -d issue分支

分支操作

# 创建并切换到newbranch分支
git checkout -b newbranch
# 分支重命名dev
git branch -m newbranch dev
# 创建远程dev分支，并push
git push origin dev
# 删除本地dev分支
git branch -d dev
# 删除远程dev分支
git push origin --delete dev

# 查看分支
git branch -v
# 查看当前分支merge关系
git branch --merged/--nomerged

分支开发工作流

长期分支

只在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。 这样，在确保这些已完成的主题分支（短期分支，比如之前的 iss53 分支）能够通过所有测试，并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布。

主题分支

只在本地git版本库中，不与服务器发生交互

主题分支是一种短期分支，它被用来实现单一特性或其相关工作。 也许你从来没有在其他的版本控制系统（VCS）上这么做过，因为在那些版本控制系统中创建和合并分支通常很费劲。然而，在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。

远程分支

远程引用是对远程仓库的引用（指针），包括分支、标签等等。 你可以通过 git ls-remote 来
显式地获得远程引用的完整列表， 或者通过 git remote show 获得远程分支的更多信息。 然
而，一个更常见的做法是利用远程跟踪分支。

head中留存的是远程分支的指针

git remote -v
git remote show origin
# 拉取远程分支到本地head
git fetch
# 合并
git pull = git fetch + git merge origin/<branchName>
# 查看本地分支和远程分支的差异
git branch -vv
# 删除远程分支
git push origin -d <branchName>

变基

善待同事Skill GET
整合分支主要方法：merge、rebase

变基需要遵守的准则：如果提交存在于仓库之外，那么不要执行变基——私有仓库/分支使用，如果已经提交出去的分支不要执行变基，可能丢失别人的修改！不要尝试在仓库外变基，否则人民群众会仇恨你，你的朋友和家人会嘲笑你，唾弃你。

变基的意义：merge和rebase在实现的最终结果上没什么区别，但是可以使提交历史更加整洁。尽管开发工作是并行的，但是看上去像是串行的，一般这么做的目的是为了确保向远程分支推送时能保持历史的整洁。应用场景：首先在自己的分支进行开发，完成时变基到origin/main上，然后向主项目提交修改，这样该项目的维护者就不需要进行整合操作，只需要快速合并便可。

• merge:两个分支，三方合并，形成新的快照

  git merge experiment
  

  

• rebase:找出C3、C4共同祖先C2，将C4修改指针只想C3，最后合并

  git checkout experiment
  git rebase master
  git checkout master
  git merge experiment
  

  

服务器上的git

略

如何对开源项目做贡献

1. fork开源项目
2. 修改、推送到自己的私有仓库
3. 请求维护者拉取自己的更新
4. 维护者合并修改，推送到主仓库