/

/git/git

在 Git 出现之前，开发者通常使用集中式版本控制系统（如 CVS 和 SVN）来管理项目。然而，这些系统存在几个主要问题：

Git 的作用和解决的问题

快速实践

1. 安装 Git

首先，你需要安装 Git。如果你还没安装，可以从 Git 官网下载并安装 Git。

在安装完成后，通过命令行验证 Git 是否安装成功：

git --version

2. 设置用户名和邮箱

Git 会使用用户名和邮箱来标记提交的作者信息。

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

3. 创建一个新的 Git 仓库

创建一个新项目的目录，并在其中初始化 Git 仓库，git init 会在当前目录中创建一个空的 Git 仓库。

# 创建目录
mkdir my-project
cd my-project
# 初始化
git init
# 该方法是已经存在远程库，直接从远程库上clone下来
git clone 远程库地址

4. 添加文件并进行初次提交

echo "# My First Git Project" > README.md
git add README.md
# 提交
git commit -m "Initial commit"

5. 推送到远程仓库（可选）

git remote add origin https://github.com/yourusername/my-project.git
git push -u origin main

Git 配置

# 配置git的用户名和邮箱 
git config [user.name](http://user.name/) "user1"
git config user.email "[user1@163.com](mailto:user1@163.com)"
# 全局配置
git config --global user.name xxx
git config --global user.email xxx
# 换行符号的自动设置（是否打开）
Git config --global core.autocrlf false
# 关闭证书校验
git config --system http.sslverify false
# 更新git配置文件中证书存放位置信息：
git config --system http.sslcainfo "D:/ProgramFiles/Git/mingw64/ssl/certs/ca-bundle.crt"

常用命令收集

# 创建一个 git 仓库 
git init
git init --bare .git
# 查看状态
git status
# 添加记录
git add file.txt
git add *.txt     提交所有文件
# 提交
git commit - m "msg"
# 从运程库克隆到本地
git clone username@domain:path
# 比如github的版本库一般是git@github.com:用户名/版本库名
# 从远端版本库更新到本地
git pull
# 从本地上传到远端版本库
git push
# 撤消跟踪
git reset head file.txt
# 修改提交
git commit -a -m "msg"
# 添加到上一次add中
git commit --amend
# 撤销 git 的上一个 commit
git reset --soft HEAD^
 --soft  不删除工作空间改动代码，撤销commit，不撤销 git add.
 --hard  删除工作空间改动代码，撤销commit，撤销 git add.
 注意完成这个操作后，就恢复到了上一次的commit状态。
# 创建分支
git checkout -b 分支名称
# 提交并创建分支
git push -u origin 分支名称
# 分支合并
git checkout week        切换到week分支
git commint -a -m "msg"  提交修改           
git checkout master      切换到master分支
git merge week           将week合并到master        
 
# 删除分支
git checkout master      切换到master分支
git branch -d 分支名称     删除
git push origin --delete 分支名称    同步到远程版本库
###################################################
# 进行栈存
git stash
 当您想记录工作目录和索引的当前状态，但又想返回一个干净的工作目录时，请使用git stash。
 该命令将保存本地修改，并恢复工作目录以匹配头部提交。
 stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。
# 保存当前未commit的代码  
git stash  
  
# 保存当前未commit的代码并添加备注  
git stash save "备注的内容"  
  
# 列出stash的所有记录  
git stash list  
  
# 删除stash的所有记录  
git stash clear  
  
# 应用最近一次的stash  
git stash apply  
  
# 应用最近一次的stash，随后删除该记录  
git stash pop  
  
# 删除最近的一次stash  
git stash drop  
###################################################
git cherry-pick 
 对于多分支的代码库，将代码从一个分支转移到另一个分支是常见需求。
 这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并（git merge）。
 另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 cherry pick。
git cherry-pick 
 上面命令就会将指定的提交commitHash，应用于当前分支。
 这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。
 举例来说，代码仓库有master和feature两个分支。
   # a - b - c - d   Master
   #      \
   #        e - f - g Feature
   
 现在将提交f应用到master分支
 切换到 master 分支$ git checkout master
 cherry pick 操作 git cherry-pick f
 上面的操作完成以后，代码库就变成了下面的样子
   # a - b - c - d - f   Master
   #      \
   #        e - f - g Feature
 从上面可以看到，master分支的末尾增加了一个提交f。
 git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交。
git cherry-pick A..B 
 上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。
 注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。
git cherry-pick A^..B 
 git cherry-pick命令的常用配置项如下。
   #（1）-e，--edit         打开外部编辑器，编辑提交信息。
   #（2）-n，--no-commit    只更新工作区和暂存区，不产生新的提交。
   #（3）-x                 在提交信息的末尾追加一行(cherry picked from commit ...)，方便以后查到这个提交是如何产生的。
   #（4）-s，--signoff      在提交信息的末尾追加一行操作者的签名，表示是谁进行了这个操作。
   #（5）-m parent-number，--mainline parent-number    如果原始提交是一个合并节点，来自于两个分支的合并，那么 Cherry pick 默认将失败，因为它不知道应该采用哪个分支的代码变动。-m配置项告诉 Git，应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号。
# 代码冲突: 如果操作过程中发生代码冲突，cherry pick 会停下来，让用户决定如何继续操作。
#（1）--continue
git cherry-pick --continue
 用户解决代码冲突后，第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 Cherry pick 过程继续执行。
#（2）--abort
 发生代码冲突后，放弃合并，回到操作前的样子。
#（3）--quit
 发生代码冲突后，退出 cherry pick，但是不回到操作前的样子。

总结工具类型优点缺点典型使用场景

Git

分布式 VCS

- 分布式架构，支持离线操作- 快速且轻量化的分支管理- 良好的社区支持和扩展性- 高效存储与检索

- 对新手学习曲线较陡峭- 合并冲突时复杂项目的管理较为繁琐

- 开源项目- 大规模分布式团队开发

Subversion (SVN)

集中式 VCS

- 简单易用，学习曲线平缓- 中央服务器可控制代码访问- 高效处理大文件

- 依赖中央服务器，离线操作有限- 分支管理较重，操作较慢

- 小型团队项目- 非分布式环境

Mercurial

分布式 VCS

- 学习曲线平缓- 分布式架构，与 Git 类似- 处理大项目性能较好

- 社区活跃度较 Git 低- 一些高级功能相比 Git 较弱

- 开源项目- 分布式开发环境

Perforce

集中式/分布式混合 VCS

- 强大、快速，适合处理超大规模项目- 优秀的大文件和二进制文件管理- 分布式和集中式混合模式

- 配置复杂，非开源- 商业授权费用较高

- 游戏开发- 大型企业软件开发

Git 在市场中占据主导地位，适合大多数项目，特别是开源项目和大型团队开发。SVN 仍然在许多企业中使用，适合简单需求的集中式版本控制。Mercurial 类似 Git，但简化了操作，适合需要分布式且希望降低复杂度的项目。Perforce 和 Plastic SCM 则专注于企业级项目，尤其是对大文件和二进制文件的处理，广泛应用于游戏开发等行业。

致谢

更多内容欢迎关注 [ 小巫编程室 ] 公众号，喜欢文章的话，也希望能给小编点个赞或者转发，你们的喜欢与支持是小编最大的鼓励，小巫编程室感谢您的关注与支持。好好学习，天天向上(good good study day day up)。

参考资料

[1]官网:/

[2]源码库:/git/git

[3]Github 官网:

[4]Gitee 官网: