开发框架06-集成GIT版本控制系统

type

date

slug

FAQs

1. 切换成 https协议连接github

2. git 路径中文显示为数字

CheetSheet

Introduction

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

SVN and Git Diff

Features

https://git-scm.com/about/branching-and-merging

Staging Area

Unlike the other systems, Git has something called the "staging area" or "index". This is an intermediate area where commits can be formatted and reviewed before completing the commit.

Quickly stage some of your files and commit them without committing all of the other modified files in your working directory

just add a '-a' to your commit command in order to add all changes to all files to the staging area.

This allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as needed.

Common Workflow

Subversion-Style Workflow

2. Integration Manager Workflow (open source or Github repositories)

3. Dictator and Lieutenants Workflow (linux kernel)

sudo apt install git

01. git init

02. git config

local ./git/config

global ~/.gitconfig

system /etc/gitconfig

从低级别确定

03. File Status Lifecycle

Hash 值

Location: .git/objects/[filename](The two first characters of hash value)

Check Command:

echo “se”

04. Git Commit Time Metaphor

场景1：恢复 git reset --hard

git add 命令提交到暂存区，git reset HEAD demo1就是把提交到暂存区里的文件撤销

git commit 提交本地仓库，git reset --soft HEAD^，会撤销commit，本地的保存还在，也就是变回待提交状态

git commit 提交本地仓库，git reset --hard HEAD^，撤销会把本地文件也会删除

如果误操作了如何恢复

命令	提交历史	暂存区(Index)	工作目录	文件修改状态
git reset HEAD~1	回退1个	清空	保留	unstaged
git reset --soft HEAD~1	回退1个	保留	保留	staged
git reset --hard HEAD~1	回退1个	清空	清空	丢失

最安全的方式

是使用 git reset HEAD~1（混合重置--mixed 默认方式），这样：

取消了commit

文件状态变为unstaged

可以重新编辑和分批提交

05. Git Delete Command

All the files (new-modified) you want to include in the next commit have to be staged using the git add command

Git reset is a powerful command, and it can be completely destroy your actual work if used improperly. Do not play with it if you don't know exactly what you are doing

unstaging file

06. Git Branching

分支管理（推荐方式）

标签管理（版本发布）

场景1：基于当前版本开发新功能

场景2：回到上一版本继续开发

当前版本已有修改，包括git commit后staged状态，还有修改但未提交的unstaged状态的。

工作目录的修改（未staged）

如果文件在两个版本间没有冲突：修改会被保留

如果文件在两个版本间有冲突：Git会拒绝切换并报错

安全的操作方式：

方案1：先保存修改

方案2：提交后再切换

方案3：创建分支保存当前状态

建议：切换版本前先用 git stash 或 git commit 保存修改，避免意外丢失代码。

场景3：合并开发分支

场景4：版本比较和恢复

场景5：对比git reset 和 git checkout

git checkout 和 git reset 的核心区别和使用场景对比：

核心概念差异

方面	`git checkout`	`git reset`
主要用途	切换分支/版本，更新工作目录	移动当前分支的HEAD指针
影响范围	不改变分支历史	改变当前分支的提交历史
安全性	相对安全	可能有破坏性（特别是--hard）

详细对比

1. 版本切换行为

`git checkout`

`git reset`

2. 文件操作差异

`git checkout` - 恢复特定文件

`git reset` - 取消staging

3. 分支操作

`git checkout` - 分支切换

`git reset` - 只影响当前分支

使用场景对比

`git checkout` 适用场景

浏览历史版本

分支管理

恢复特定文件

`git reset` 适用场景

修改提交历史

取消staging

回退版本

安全性对比

`git checkout` 的保护机制

`git reset` 的风险

恢复误操作

checkout误操作恢复

reset误操作恢复

新语法替代

Git 2.23+ 引入了更清晰的命令：

总结

checkout: 用于浏览、切换，不改变分支历史

reset: 用于修改当前分支的提交历史

选择原则: 需要改变历史用reset，需要切换查看用checkout

07. Git Stash

两个分支进行开发，一个分支已开发但未提交的功能会影响到另一分支在开发调试时的本地编译，因此需要

08. Git.ignore file

解决方法: git清除本地缓存（改变成未track状态），然后再提交:- 我直接重新来了。搞定

需要特别注意的是：

1）.gitignore只能忽略那些原来没有被track的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。

2）想要.gitignore起作用，必须要在这些文件不在暂存区中才可以，.gitignore文件只是忽略没有被staged(cached)文件，

对于已经被staged文件，加入ignore文件时一定要先从staged移除，才可以忽略。

09. Git working with remotes

场景1：添加到远程仓库(Gitee为例)

gitee.com 网站创建仓库（按指示先设置用户名和邮箱，我们这里已经创建了本地仓库，只需要git remote操作后推送内容到远程仓库）

若本地仓库尚未创建，初始化，添加add 并提交首次commit后，即可添加到远程仓库

10. Git remote operation

场景1：协作 git pull 防止覆盖

本地修改和远端仓库修改，git pull 覆盖本地

场景2：子模块管理

目标

子模块修改可以提交远程代码库

其他项目可以获取子模块最新提交

添加子模块

生成两个文件 .gitmodules （记录了子项目的目录，子项目的git地址信息）和 lettershell

两个文件都需要提交到父项目的git中。

更新子模块

克隆子模块

总体示例

Git: submodule 子模块简明教程 - 知乎 (zhihu.com)

使用Git Submodule管理子模块 - 姜家志 - SegmentFault 思否

场景3：本地管理两个 GitHub 账户完整指南

解决fork和upstrem冲突

一、SSH 密钥配置

1. 为每个账户生成独立的 SSH Key

2. 将公钥添加到对应的 GitHub 账户

分别登录对应的 GitHub 账户，在 Settings → SSH and GPG keys 中添加相应的公钥。

3. 配置 SSH config 文件

添加以下配置：

4. 添加密钥到 SSH Agent

5. 测试 SSH 连接

应该分别显示：

Hi user1! You've successfully authenticated...

Hi user2! You've successfully authenticated...

二、Fork 和 Clone 工作流程

1. GitHub 上 Fork 仓库

使用 user2 账户：

访问原始仓库（如 tangly1024/NotionNext）

点击 "Fork" 按钮

Fork 到 user2 账户下

2. Clone 仓库到本地

3. 配置远程仓库

正确的配置应该显示：

4. 配置项目级别的 Git 用户信息

三、解决冲突并推送的完整流程

1. 同步上游仓库

2. 合并上游更改

3. 解决冲突

4. 提交解决的冲突

5. 推送到你的 Fork

四、关键问题解决方案

问题：SSH 密钥找不到或权限被拒绝

解决方案：更新远程仓库 URL 使用正确的 SSH Host

问题：用户身份混淆

解决方案：为每个项目单独配置用户信息

五、常用命令速查表

六、最佳实践

命名规范：使用清晰的 SSH Host 名称区分不同账户

项目隔离：每个项目单独配置用户信息，避免提交混乱

定期同步：定期从 upstream 获取更新，减少冲突

备份策略：重要更改前创建备份分支

URL 一致性：确保 origin 和 upstream 使用相同的 SSH Host 配置

七、故障排除

如果遇到问题，按以下顺序检查：

SSH 连接测试：ssh -T [email protected]

远程仓库配置：git remote -v

用户配置：git config user.name 和 git config user.email

SSH Agent：ssh-add -l 检查已加载的密钥

重新添加密钥：ssh-add ~/.ssh/id_ed25519_user2

这套配置方案经过实战验证，可以有效管理多个 GitHub 账户，避免权限和身份混淆问题。

11. 同时操作多个remote,本地如何同步到remote

基于github搭建博客系统

Reference

tutorialspoint Git - Quick Guide (English Verson)

An Intro to Git and GitHub for Beginners (Step-to-Step Tutorial)

runoob.com Git 教程(chinese Version)

Github Guides (Systematic and Brilliant)

汪文君Git实战视频

廖雪峰 Git讲解