Git操作指南

参考文献
Github docs

Git操作指南

Git 是一种分布式版本控制系统，用于跟踪文件的修改历史和协作开发。它可以记录文件的所有修改、修改者、修改时间等信息，并将这些信息存储在一个称为“仓库”（repository）的地方。Git 可以让多个开发者在同一个代码库上协作，同时保持代码的版本控制和完整性。

1. 安装

安装 Git 通常有几种方法，下面列出了其中的两种常见方法：

方法一：通过 Git 官方网站下载安装程序进行安装。

1. 访问 Git 官方网站：https://git-scm.com/downloads
2. 根据你的操作系统选择下载相应的安装程序。
3. 下载完成后，运行安装程序，并按照提示进行安装。

方法二：使用包管理器安装 Git（适用于 Linux 系统）

1. 在终端中输入以下命令以更新包列表：

sudo apt update

2. 安装Git：

sudo apt install git

3. 等待安装完成后，可以输入以下命令来检查 Git 是否已成功安装：

git --version

如果 Git 已成功安装，会显示 Git 的版本号信息。

无论使用哪种方法安装 Git，安装完成后都可以在终端或命令行中运行 Git 命令。

• 针对 OS X 的安装。

brew install git

• 针对 Fedora 和使用 yum 的 Linux 发行版的安装。

yum install git

2. 更新Git

# windows下
git update-git-for-windows

3. 在命令行上访问Git帮助

git help 

查看所有话题的列表

git help --all 

查看 Git 的术语词汇表

git help glossary

4. Git的常见命令

• git init：将当前目录转换为 Git 仓库。
• git clone：将远程仓库克隆到本地。
• git add：将文件添加到暂存区。
• git commit：将暂存区中的文件提交到本地仓库。
• git push：将本地仓库中的文件推送到远程仓库。
• git pull：从远程仓库拉取最新的版本并合并到本地仓库。
• git branch：查看或创建分支。
• git checkout：切换分支或恢复文件到指定版本。
• git merge：将两个分支合并。
• git status：查看仓库状态，包括未提交的修改和已提交的文件。
• git log：查看提交历史。

5. 配置Git

5.1 查看当前所有配置

git config --list

这将列出你的全局Git配置。如果要查看仓库级别的配置，请在仓库的根目录中运行该命令。

注意：全局设置储存在 ~/.gitconfig 文件中，而本地设置储存在正在工作的仓库中的 .git/config 文件中。

你可以使用上述命令在任何一个级别中设置或查看配置。

5.2 配置用户信息

这里设置的 姓名 和 邮箱地址 会用在 Git 的提交日志中，会随着提交日志一同被公开。

• 配置你的名字

git config --global user.name 'Your Name' 

• 配置你的电子邮件地址

git config --global user.email 'Your email@example.com'

注意：对于特殊项目设置，用 --local 替换 --global，然后应用配置命令。

5.3 配置编辑器（可选）

如果你想使用不同于默认编辑器的编辑器，例如 vim ，可以运行以下命令：

git config --global core.editor "vim"

如果想要更改 Windows 的编辑器，则需要加入应用文件的完整路径。

git config --global core.editor '"C:\Program Files\Vim\gvim.exe" --nofork'

--nofork 选项告诉Vim在前台打开文件并在文件保存后立即退出，这有助于避免与Git命令之间的交互问题。

5.4 配置命令行颜色（可选）

git config --global color.ui true  # 在终端中显示彩色的Git输出
git config --global diff.ui auto   # 在显示差异（diff）时使用彩色输出

5.5 行结束符问题

如果开发者使用不同的操作系统，可能会导致行结束符问题。不同的操作系统使用不同的行结束符

• Windows 使用 CRLF（回车和换行）
• Unix/Linux 使用 LF（换行）

为了避免这些问题，你可以使用core.autocrlf配置项将行结束符转换为你喜欢的格式。core.autocrlf有三个可能的值：

• input：这是默认值。它告诉 Git 在检出文件时不转换行结束符，但在提交时将行结束符转换为 LF 格式。
• true：这告诉 Git 在检出文件时将行结束符转换为 CRLF 格式，在提交时将行结束符转换为 LF 格式。
• false：这告诉 Git 不要自动转换行结束符。

如果你使用的是 Unix/Linux 系统，则建议将 core.autocrlf 设置为 input。如果你使用的是 Windows 系统，则建议将其设置为true。

git config --global core.autocrlf input  # 这将在检出文件时不转换行结束符，但在提交时将行结束符转换为LF格式。

如果你在一个特定的仓库中需要使用不同的行结束符转换规则，你可以在该仓库的根目录中创建一个名为 .gitattributes 的文件，并在其中添加适当的行结束符转换规则。

例如，要将一个仓库中的所有文件转换为 CRLF 格式，可以将以下内容添加到 .gitattributes 文件中：

# 设置所有文件的默认行为
*.text=auto

# 列出应使用系统相关的行结束符的文本文件
*.php text
*.html text
*.css text  

# 列出应使用 CRLF 行结束符且不根据本地操作系统转换的文件 
*.sln text eol=crlf  

# 列出所有不应进行修改的二进制文件 
*.png binary  
*.jpg binary  
*.gif binary  
*.ico binary 

5.6 Windows中文乱码问题

在 Windows 中使用 Git 时，中文文件名可能会出现乱码的问题。为了解决这个问题，你可以使用以下命令在全局级别禁用对文件名的引用：

git config --global core.quotepath false

5.7 设置SSH密钥

SSH密钥 是一种用于安全通信的加密密钥，通常用于远程登录和文件传输。在 SSH 协议中，每个用户都会有一对密钥：私钥和公钥。私钥只能由用户拥有，并用于对传输的数据进行加密和签名，而公钥可以向其他人公开，并用于解密和验证数据的来源。

在 Git 中，使用 SSH 密钥是与远程 Git 仓库进行安全通信的一种常见方式。当你与远程 Git 仓库进行通信时，Git 会使用 SSH 协议进行加密通信，从而确保你的数据不会被篡改或窃取。在设置 SSH 密钥时，你将生成一对密钥：私钥和公钥。私钥存储在本地计算机上，而公钥存储在远程 Git 仓库中。当你进行与远程 Git 仓库的通信时，Git 会使用私钥对传输的数据进行加密和签名，从而确保数据的安全性。

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

-t 表示密钥的类型 ，-b 表示密钥的长度，-C 用于识别这个密钥的注释 ，这个注释可以输入任何内容。

生成的SSH密钥将存储在你的计算机的默认 SSH 密钥存储目录中，一般是在 ~/.ssh 目录中。

ssh-keygen 是一个用于生成 SSH 密钥对的命令行工具，它可以使用多种密钥协议生成密钥对，常见的有以下几种：

• RSA（Rivest–Shamir–Adleman）：RSA 是最常用的 SSH 密钥协议之一，它基于一种非对称加密算法，具有较高的安全性和性能。

• DSA（Digital Signature Algorithm）：DSA 是另一种非对称加密算法，它比 RSA 更快，但通常需要更长的密钥长度才能提供相同的安全性。

• ECDSA（Elliptic Curve Digital Signature Algorithm）：ECDSA 是基于椭圆曲线加密算法的一种 SSH 密钥协议，相比 RSA 和 DSA，它使用更短的密钥长度提供相同的安全性，因此更适合在资源受限的设备上使用。

• Ed25519：Ed25519 是一种基于椭圆曲线加密算法的 SSH 密钥协议，它提供与 RSA 相当的安全性，但生成和验证密钥的速度更快。

这些协议在 SSH 密钥对生成时可以通过 ssh-keygen 命令的参数指定，例如：

ssh-keygen -t rsa # 生成 RSA 密钥对 

ssh-keygen -t dsa # 生成 DSA 密钥对 

ssh-keygen -t ecdsa # 生成 ECDSA 密钥对 

ssh-keygen -t ed25519 # 生成 Ed25519 密钥对

5.8 配置代理（可选）

本地开启 VPN 代理后，Git 也需要设置代理。否则就会出现能访问 GitHub 网站，但是 git push 超时等情况。

• 设置全局 http/https 代理

# 不同代理的端口号不一样
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy https://127.0.0.1:7890


# 或者有时候
git config --global http.proxy 'socks5://127.0.0.1:7890' 
git config --global https.proxy 'socks5://127.0.0.1:7890'

• 取消全局 http/https 代理（如果不用 VPN，记得取消代理）

git config --global --unset http.proxy

git config --global --unset https.proxy

• 设置 ssh 代理，需要新建并配置一个 config。

  • linux、MacOS系统：~/.ssh/config

  • Windows系统：C:/Users/用户名/.ssh/config

在SSH连接时，这个配置文件通常被用来设置主机别名、指定用户和身份验证方法等。

Host example.com  # 主机别名
  HostName example.com # 主机名
  User username        # 用户名
  IdentityFile ~/.ssh/id_rsa # 身份验证方法
  
Host github.com
  HostName github.com 
  User git 
  IdentityFile ~/.ssh/github_rsa 

Host gitee.com
  HostName gitee.com 
  User git 
  IdentityFile ~/.ssh/gitee_rsa 

一个详细的基于自己的代理案例

# Windows，注意替换端口号和 git\mingw64\bin\connect.exe 的路径
ProxyCommand "D:\Program Files\Git\mingw64\bin\connect" -S 127.0.0.1:7890 -a none %h %p

# MacOS，注意替换端口号
ProxyCommand /usr/bin/nc -v -x 127.0.0.1:7890 %h %p

# 备用主机名
Host github.com
  Hostname ssh.github.com
  User git
  Port 443
  TCPKeepAlive yes
  IdentityFile "C:\Users\用户名\.ssh\id_rsa"

# 备用主机名
Host gitlab.com
  Hostname altssh.gitlab.com
  User git
  Port 443
  PreferredAuthentications publickey
  IdentityFile "C:\Users\用户名\.ssh\id_rsa"

需要注意的是，如果使用 HTTPS 协议可能更加稳定，可以尝试使用HTTPS 协议进行连接。

ssh.github.com 是 Github 的 SSH 代理服务器地址。当你在使用 Git 命令或者其他 Git 工具时，如果直接连接 Github 的 SSH 服务github.com，可能会因为网络限制或其他原因导致连接失败。为了解决这个问题，Github 提供了一个 SSH 代理服务器ssh.github.com，可以通过这个代理服务器来连接 Github 的 SSH 服务。

保存后 config 文件后测试方法如下，返回 successful 或者 welcome 之类的就成功了。(需要保证已经讲SSH公钥添加到托管平台)

# 测试是否设置成功
ssh -T git@github.com

ssh -T git@gitlab.com

测试成功后会在~/.ssh 生成known_hosts。known_hosts 是 SSH 客户端用来记录远程 SSH 服务器的公钥指纹的文件。在 SSH 连接建立时，客户端会检查该文件中是否存在远程主机的公钥指纹。如果公钥指纹匹配，则说明远程主机是可信的，客户端会接受连接并建立 SSH 会话。如果公钥指纹不匹配，则说明远程主机的身份可能受到篡改或欺骗，客户端会拒绝连接并给出警告信息，以防止中间人攻击。

当第一次连接到一个新的 SSH 服务器时，SSH 客户端会自动将该服务器的公钥指纹保存到 known_hosts 文件中。这样，在以后的连接中，客户端就可以比较该服务器的公钥指纹和 known_hosts 文件中的记录来验证服务器的身份。该文件的格式是每行一个记录，其中包含了远程服务器的 IP 地址、公钥指纹以及可选的注释信息。在一些情况下，如果你不想保存某个主机的公钥指纹，你可以手动编辑 known_hosts 文件并删除相应的记录。

Git托管平台(基于GitHub)

三个流行的协作平台：GitHub、Bitbucket 和 GitLab。在 GitHub 上托管开源项目，在 Bitbucket 上托管私有客户工作，以及 GitLab 上的内部自治项目。

1. 创建账号

1.1 创建账号

1. 访问 https://github.com

2. 输入一个未被占用的用户名。GitHub 会告诉你这个名称是否已经被使用。

3. 输入一个合法的电子邮件地址。

4. 输入一个安全的密码。

5. 点击 Sign up for GitHub（注册 GitHub 账户）按钮继续。

1.2 选择付费方案

1. 确认你希望启用的方案类型。默认情况下，免费方案是被选中的。

2. 通过点击 Finish sign up（完成注册）完成账户创建过程。

1.3 设置SSH

1. 访问 https://github.com/settings/ssh

2. 在 SSH Keys 摘要页面，点击 Add SSH key（添加 SSH 密钥）。

3. 可选择是否为你的 SSH 密钥添加一个标题。

4. 将你之前复制的公钥粘贴到 Key（密钥）字段中。

5. 点击 Add key（添加密钥）按钮。

2. 创建组织

2.1 创建组织

1. 从顶部的菜单中，点击头像左边的 + 符号。

2. 点击 New Organization（新建项目）。你将会被重新定向到新组织的设置表单。

3. 在 Create an organization（创建新组织）的表单中，输入以下信息。

   • Organization Name（组织名）：这将会是你项目 URL 的一部分。
   • Billing email（账单寄送电子邮件地址）：即使你选择免费方案，这个字段也是必填的。
   • Plan（方案）：默认选择开源。

4. 点击 Create organization（创建组织）以继续。

2.2 邀请成员

1. 在搜索框中，输入你想要添加的成员的名字或用户名。

2. 点击成员名字右边的 + 符号。

3. 重复第 (1) 步和第 (2) 步，添加所有成员。

4. 点击 Finish（完成）来发送邀请。

基于issue的工作流程

1. 基本步骤

GitHub 的 issue 是一种让用户和团队成员之间协作交流的方式，可以用来报告 bug、提出功能请求、讨论设计问题、寻求帮助等。下面是一个基本的 GitHub issue 流程：

1. 打开项目页面，点击Issues选项卡。

2. 点击New issue按钮，创建一个新的 issue。

3. 在标题栏中简要概括问题，然后在正文中详细描述问题。

4. 如果有必要，可以使用标签、里程碑和分配器等功能来进一步组织和跟踪问题。

5. 在本地仓库中，使用 issue+number 格式创建一个新的分支。

6. 完成工单描述的工作（且只完成工单中描述的工作）。

7. 测试工作，确保已经完成并且是正确的。确保它能够通过开发环境下的 QA 测试。

8. 将更改添加到本地仓库的暂存区。

9. 将缓存的修改提交至仓库。

10. 将更改推送到备用服务器上，如 GitLab、Bitbucket 或 GitHub。根据工单系统，可以将这个工单标记为已解决， 但不需要将其标记为已关闭。

11. 当对工作完全满意时，将工单分支并入主分支（通常是 main）并将修改后的分支推送到代码托管系统中。

12. 再一次测试工作，确保没有后续问题。

13. 将工单标记为已关闭。

通过正确使用 GitHub issue，可以帮助您的团队更好地管理项目和交流，并使项目更加高效和有组织。在实际使用中，还可以根据实际情况进行微调或扩展。例如，可以添加一个 Code Review 步骤，让团队成员对代码进行评审，以确保代码质量和合规性。还可以使用 Git Hooks 等工具来自动化某些流程，例如自动化测试和代码风格检查。

2. 创建issue模板

在 GitHub 上创建 issue 模板，可以让贡献者更好地理解问题的需求，并更容易地与问题描述对齐。以下是如何创建一个 issue 模板的步骤：

1. 打开你的 GitHub 仓库，并点击 Settings 选项卡。
2. 在 Features，你会看到 Set up templates 按钮，点击它。
3. 点击 Add template 按钮。
4. 给你的模板命名，并填写模板的正文，使其包含你想要贡献者填写的问题信息。
5. 保存模板，并确保它已被正确添加到你的仓库中。

会在仓库的.github/ISSUE_TEMPLATE下生成模板

• Bug Report模板

**提交 issue 前，请先确认：**
- [x] 我已看过 **README**，此问题不在列表中
- [ ] 我已看过其他 issue，他们不能解决我的问题 

**表现**  
清晰准确的描述 BUG 的表现情况

**运行环境:**  
- 操作系统：？
- Docker： ？
- 项目版本：？

**复现步骤**  
描述你是如何触发这个 BUG 的
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

**预期行为**  
描述你认为正常情况下应该看见的情况

**截图**  
相关日志、聊天记录的截图，没有可跳过

**其他内容**  
此处填写其他内容，没有可跳过

• Feature request模板

您的功能请求是否与问题有关？请描述。对问题的清晰而简明的描述。例如，当...时，我总是感到沮丧。

描述您想要的解决方案。对您希望发生的事情进行清晰而简洁的描述。

描述您已考虑过的替代方案。对您已考虑过的任何替代解决方案或功能进行清晰而简洁的描述。

附加上下文。在此处添加有关功能请求的任何其他上下文或屏幕截图。

基于Project的工作流程

GitHub 的 Project 是一种协作工具，可以帮助团队组织任务和跟踪进度。下面是使用 GitHub Project 的基本步骤：

1. 创建项目：在你的 GitHub 仓库中创建一个项目。
2. 添加列：为你的项目添加不同的列，例如“待办事项”、“进行中”和“已完成”。
3. 创建卡片：为每个任务创建一张卡片，并将其添加到适当的列中。卡片可以包含有关任务的详细信息和描述，可以分配给不同的人员，并附有标签和里程碑等元数据。
4. 移动卡片：当任务的状态发生变化时，将卡片移动到正确的列中。
5. 跟踪进度：通过检查卡片的状态和列中的任务数量，跟踪项目的进度和状态。
6. 协作：团队成员可以协作在卡片上，评论和讨论任务，提出问题和建议等。

GitHub Project 有许多高级功能，例如自动化、过滤器、排序和时间跟踪等，可以根据需要进行配置。

Wiki——项目使用指南

GitHub 的 Wiki 是一个用于存储和共享文档的功能，可以用于记录项目相关的文档、知识点、指南等。下面是使用 GitHub 的 wiki 的步骤：

1. 在你的 GitHub 项目主页上点击Wiki 标签。
2. 如果你还没有启用 wiki，点击 Create the first page 开始创建第一页，然后输入页面标题和内容并提交。
3. 如果你已经有了 wiki 页面，点击 Create new page 或 Edit 来创建或编辑页面。你可以使用 Markdown 语法来编写页面，GitHub 会自动将其转换为 HTML 格式。
4. 如果你需要添加图片或其他文件，可以先将它们上传到你的项目的仓库中，然后在 wiki 页面中使用相应的链接来引用它们。
5. 你还可以使用 GitHub 的协作功能来邀请其他人参与编辑和管理 wiki 页面。在页面右侧的 Settings 中，你可以选择允许哪些人对 wiki 页面进行编辑和管理。
6. 如果你需要查找和浏览 wiki 页面，可以使用 GitHub 的搜索功能，在项目主页的搜索框中输入关键词即可找到相关的页面。

总的来说，使用 GitHub 的 wiki 可以方便地记录和共享项目相关的文档和知识，提高团队协作效率。

常用的项目操作

1. 创建本地仓库

第一种情况：克隆已有的仓库项目

创建项目克隆将会下载仓库中所有文件的副本及其提交历史，它还会记住你下载代码的地方，将远程代码托管服务器设置为跟踪仓库。直接下载压缩包解压则没有这个功能。

git clone 链接

第二种情况：初始化已有的本地项目

• 初始化目录：直接下载压缩包解压，git自动感知目录下的所有文件，包括子目录

git init

• 检查仓库的当前状态

git status

• 将仓库中所有文件添加至暂存区

git add --all
或者
git add .

• 将当前暂存区中的文件保存到仓库的历史记录中

git diff HEAD              # 查看更改前后的差别
git commit -m "文本"

第三种情况：初始化空项目

# 创建一个文件夹，用于存放项目，无论在任何地方git都不关心
# 在创建好的新文件夹下初始化
git init

2. 查看历史记录

查看本地仓库当前签出分支中的每个提交的提交消息和作者信息

git log                # 能查看以当前状态为终点的历史日志，按q退出
git log --oneline      # 每个日志只显示一行
git log -10            # 显示最近的10个log
git log 文件或者日志名    # 指定查看日志 
git log -p             # 显示出具体改动
git reflog             # 查看当前仓库的操作日志

3. 分支的操作

分支在 Git 中非常重要，它允许你在同一个仓库中同时进行多个不同的工作流程，同时分支分为本地分支和远程分支，使用时候要分清楚。通常，在开始新的功能开发之前，你应该从主分支（如 main 分支）创建一个新的分支，例如 feature-branch。在这个分支上进行开发，直到功能开发完毕并经过了测试，然后将分支合并回主分支。以下是一些常见的分支操作：

3.1 列出分支

# 列出本地所有分支
git branch --list

# 列出所有分支
git branch --all
# 或者
git branch -a

# 列出远程分支
git branch --remotes

3.2 更新拉取远程分支列表

git fetch

3.3 切换使用不同的分支

git checkout --track 分支名称            # 在本地创建并切换到一个新的分支，该分支会跟踪远程仓库的同名分支
									    # 如果本地没有对应的远程分支，可以先使用 git fetch 命令获取远程分支
git checkout -b 子分支名称 父分支名称      # 在本地创建、切换分支

3.4 创建新的分支

分支名应该能够反映正在进行的工作。

# 切换到一个父节点
git checkout main
# 在本地创建分支节点
git branch 子分支名称
# 签出到分支节点
git checkout 子分支名称
git checkout -b 子分支名称 main   # 在本地创建、切换分支

3.5 合并分支

# 将工单分支并入你的主分支
git checkout main
git merge --no-ff 工单分支名称          # --no-ff 为了记录合并历史，强制 Git 生成一个新的提交记录
git push --set-upstream 远程仓库名(默认是origin) 分支名称   # 将本地分支推送到远程仓库并在远程仓库中创建与本地分支同名的分支
git push --set-upstream origin main # 将本地 main 分支推送到远程仓库 origin 并在 origin 上创建名为 main 的分支

3.6 删除分支

# 删除这个分支的本地副本
git branch --delete 工单分支名称
# 或者
git branch -d 工单分支名称

# 删除不再需要的远程分支
git push --delete 远程仓库名(默认是origin) 工单分支名称

如果分支还没有被合并，将无法删除它。如果你想强制删除一个尚未合并的分支，可以使用 git branch -D <branch-name> 命令

3.7 查看分支结构

• --all: 显示所有分支的提交历史。
• --abbrev-commit: 仅显示 SHA-1 的前几个字符而不是完整的 SHA-1 值。
• --decorate: 显示每个提交所在的分支和标签。
• --date=iso: 显示提交日期的 ISO 格式。
• --pretty=format:'%h %Cgreen%ar %Creset%an %s': 指定提交历史的输出格式，这里是显示简写的 SHA-1 值、提交相对时间、作者名和提交信息。

git log --graph
git log --graph --all --abbrev-commit --decorate --date=iso --pretty=format:'%h %Cgreen%ar %Creset%an %s'

3.8 重命名分支

# 重命名当前分支
git branch -m <new_branch_name> 

# 推送新分支，从而创建一个新的远程分支
git push origin <new_branch_name> 

# 删除旧的远程分支
git push origin -d -f <old_branch_name> 

# 本地分支重命名
git branch -m oldName newName 

# 删除远程对应的旧分支：
git push origin --delete oldName 

4. 在仓库中添加更改

Git中的更改必须先进行暂存，进入缓存区，然后再保存至仓库。

# 将选中的已更改文件添加至Git仓库
git add 文件1 文件2 ...

# 递归地添加指定路径中的所有文件
git add <directory_name>/*

# 添加扩展名为.png的所有文件
git add *.png

# 暂存Git中所有已知的且在上次提交之后编辑过（或修改过）的文件
git add --update

# 暂存Git中所有已知但还没有进行暂存的文件；暂存任何当前未被Git跟踪的文件
git add --all

• 在仓库中添加部分文件修改

# 将选中的修改交互式地添加到缓存区
git add --patch filename

• 提交部分更改

# 将选中的修改交互式地添加到你的Git仓库
git commit --patch -m 'message'

• 从暂存区撤回文件

git reset HEAD 文件

• 编写扩展提交消息

# 对上一条提交的commit修改
git commit --amend

5. 连接远程仓库（在上传前要完成连接）

5.1 添加远程连接

# 使用自定义的名称在本地仓库中添加远程连接，一般用origin
git remote add <name> git@github.com:用户名/仓库名.git

# 例如
git remote add origin https://github.com/user/repo.git

# 两个远程仓库
git remote add my_github git@github.com:用户名/仓库名.git
git remote add my_gitlab git@gitlab.com:用户名/仓库名.git

# 从本地 Git 仓库中删除远程仓库
git remote remove <name>

# 列出连接至你当前仓库的远程仓库
git remote --verbose
# 或者
git remote -v

5.2 查看特定远程仓库的详细信息

git remote show <name>

5.3 重命名远程仓库

git remote rename <old-name> <new-name>

5.4 将远程分支合并到本地分支

git checkout -b feature origin/feature # 从远程分支创建本地分支并检出它

git pull origin main  # 将远程仓库origin上main分支上的更新拉取到本地仓库的main分支

git pull = git fetch + git merge

git fetch 命令用于将远程仓库的更新拉取到本地

git merge 命令用于将本地仓库的分支与远程仓库合并

5.5 推送本地分支到远程分支

git push

# 在上传本地分支时设置上游分支
git push --set-upstream 上游分支(默认origin) 当前分支

# 简化
git push -u origin main

推送到远程分支之前，需要先用 git pull 将本地分支与远程分支进行合并，或者使用 git push --force 命令强制推送

6. 回滚

命令	作用
Reset	用于将分支顶端移至一个之前的提交。重置命令可以在本地仓库中删除提交历史记录，但要注意，一旦从远程仓库中克隆的副本也将被更新。使用 git reset 命令时需要非常小心，因为它可以永久性地删除提交。
Rebase	允许您改变分支历史记录中提交的存放方式。在 rebase 期间，将基于另一个分支来更改提交，通常用于将多个提交压缩成一个提交。这个命令可以用来减少分支的历史记录并简化分支树，但在处理公共分支时需要谨慎。
Revert	用于还原共享分支上一个特定提交中做出的变更。与 reset 不同，revert 不会从提交历史记录中删除任何内容，而是创建一个新的提交来反转已经存在的提交。这个命令通常用于处理公共分支，因为它不会删除 Git 历史记录中的任何内容。需要push，相当于一个命令

6.1 git reset 回滚到某次提交

git reset [<mode>] [<commit>]

参数	作用
–soft	头部重置为<commit>，但不更改工作树或索引。这将留下所有已更改但未提交的文件的“提交更改”。
–mixed	重置索引但不重置工作树（即保留更改的文件但未标记提交）并报告尚未更新的内容。（默认）
–hard	重置索引和工作树。<commit>后对工作树中跟踪文件的任何更改都将被丢弃。这将删除所有未提交的更改。
–merge	重置索引并更新工作树中与<commit>和HEAD之间不同的文件，但保留索引和工作树之间不同的文件。
–keep	重置索引条目并更新工作树中在<commit>和HEAD之间不同的文件。

重置分支通常应该与小心谨慎地使用，因为它可以永久性地删除您的更改。建议在进行重置之前，先创建一个分支备份，以便在需要时可以回滚到以前的状态。

6.2 git revert 放弃某次提交

git revert <commit>

git revert 前后的提交仍会保留在 git log 中，而此次撤销会做为一次新的提交。如果不想编辑提交消息，则可以使用 -m 标志自动使用默认消息。例如：

git revert -m "Revert commit <commit>"

需要注意的是，git revert 撤销某个提交时，可能会导致代码冲突，需要手动解决冲突后再提交。

6.3 git rebase

• 编辑以前的提交消息
• 将多个提交合并为一个
• 删除或恢复不再需要的提交

1. 重新设置另一个分支和当前分支状态之间的所有提交，即将当前分支中的提交重新应用到目标分支上

git rebase --interactive other_branch_name

2. 对当前分支中的最后几个提交进行rebase

git rebase -i HEAD~数字  # HEAD~数字 表示最近的几个commit

3. 变基时有六个命令：

• pick：意味着包括该提交，可以更改提交的顺序。如果选择不包括提交，则应删除整行。
• reword：可以重新设置提交的消息，而提交所做的更改不受影响。
• edit：可以在 Rebase 过程中进行更多提交，然后继续 Rebase 操作，例如在两个提交之间插入更多提交。
• squash：可以将两个或多个提交合并为一个提交，而且该提交将被压缩到其上方的提交中。
• fixup：类似于 squash，但提交仅合并到其上方的提交中，并且舍弃消息。
• exec：可以对提交运行任意的 Shell 命令。

问题	解决方案
回滚本地工作区未暂存的改动	git checkout – <filename>
回滚已暂存的改动，但未被提交	git reset --hard <commit>
回滚commit所做的改动，生成新的commit，log不影响	git revert <commit>
回滚已经提交的文件改动	git rebase -i <commit>

7. 标签

标签（Tag）是一个指向特定提交的引用，通常用于标记代码库中的重要版本或发布。通过为每个版本添加标签，用户可以轻松地跟踪软件的版本，并快速访问特定版本的代码。

7.1 列显已有的标签

git tag

在 Git 自身项目仓库中，如果只对 1.0 系列的版本感兴趣，可以运行下面的命令：

git tag -l 'v1.0.*'

7.2 创建标签

创建一个含附注类型的标签

git tag -a v1.0 -m 'my version 1.0'
git show v1.0

可以在后期对早先的某次提交加注标签

# 显示单个提交的日志消息和文本diff
git show 日志ID

# 为某个提交对象添加一个新的标签
git tag 标签名称 日志ID

7.3 签署标签

如果你有自己的私钥，还可以用 GPG 来签署标签

git tag -s v1.0 -m 'my signed 1.0 tag'

7.4 删除标签

git tag -d v1.0

# 删除远程标签
git push --delete origin v1.0

7.5 轻量级标签

轻量级标签实际上就是一个保存着对应提交对象的校验和信息的文件。不用参数。

git tag v1.0-lw

7.6 验证标签

可以使用 git tag -v [tag-name] (译注：取 verify 的首字母)的方式验证已经签署的标签。此命令会调用 GPG 来验证签名，所以你需要有签署者的公钥，存放在 keyring 中，才能验证：

$ git tag -v v1.0

7.7 分享标签

默认情况下，git push 并不会把标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。其命令格式如同推送分支，运行 git push origin [tagname] 即可：

git push origin v1.0

如果要一次推送所有本地新增的标签上去，可以使用 --tags 选项：

git push origin --tags

自用初始化

git init
git remote add origin https://github.com/user/repo.git
git branch -m main
git pull origin main
git add .
git commit -m 'init'
git push -u origin main