git操作

沉香亭北
105 阅读31分钟

git

新建 Git 仓库

1. 初始化本地仓库

首先，创建一个文件夹并初始化一个 Git 仓库：

$ mkdir learn-git           # 创建一个新文件夹
$ cd learn-git              # 进入该文件夹
$ git init                  # 初始化 Git 仓库

此时会在当前目录下创建一个 .git 文件夹，Git 会在此文件夹中存储所有与版本控制相关的信息。

2. 直接指定文件夹作为仓库

如果你想直接在指定文件夹中创建一个仓库，可以使用以下命令：

$ git init my-repo           # 在当前目录下创建名为 'my-repo' 的仓库

这将在当前目录下创建一个 my-repo 文件夹，并自动初始化 Git 仓库。

总结

命令说明
git init在当前文件夹初始化一个 Git 仓库。
git init <folder_name>在指定文件夹中初始化一个 Git 仓库，文件夹会被创建。

通过以上步骤，你可以轻松创建一个新的 Git 仓库，准备开始版本控制。如果你打算在本地开发一个项目并跟踪文件变更，初始化仓库是第一步！

Git 工作区和文件状态

Git 有四个主要的区域，用于管理和跟踪文件的不同状态：工作区、暂存区、本地仓库和远程仓库。下面对它们做了优化和详细说明：

1. 工作区（Workspace）

定义：工作区是开发者实际进行代码开发和修改的地方。它就是你在文件系统中看到的文件。

  • 作用：在工作区中，所有文件都处于“未版本控制”或“已修改”状态，直到你决定将这些更改添加到暂存区或提交到仓库中。
  • 说明：任何修改（如新增、删除、修改文件）都发生在工作区，且修改不会立即被 Git 记录，只有经过暂存区和提交到本地仓库才会被版本控制。

2. 暂存区（Index / Stage）

定义：暂存区是一个虚拟的区域，存储你决定要提交的文件和它们的变更。Git 通过 .git 目录中的 index 文件来记录文件的状态，但它不保存文件内容，而是通过文件的 ID 来索引每个文件。

  • 作用：通过 git add 命令，开发者可以把文件的修改从工作区移到暂存区，这样文件的更改就被 Git 开始追踪。
  • 查看状态：使用 git status 可以查看暂存区的状态，查看哪些文件被暂存，哪些文件还没有被加入暂存区。
  • 说明：修改需要先进入暂存区，才会被版本控制。暂存区可以理解为“准备提交”的区域，只有被暂存的文件才会包含在下次提交中。

3. 本地仓库（Repository）

定义：本地仓库是 Git 用来存储所有版本历史的地方。每次你执行 git commit 时，暂存区的文件将被记录在本地仓库中。

  • 作用：本地仓库保存了所有提交记录（历史版本），它相较于工作区和暂存区来说，内容会更旧一些。执行 git commit 后，暂存区的内容会被同步到本地仓库，保存为新的提交版本。

  • 说明：

    1. 提交：只有将更改提交到本地仓库，修改才会永久保存。
    2. 初始化仓库：可以在任何地方创建本地仓库，执行 git init 即可将目录初始化为一个 Git 仓库，这样 Git 就会创建一个 .git 文件夹来存储版本历史。

4. 远程仓库（Remote）

定义：远程仓库是指托管在服务器上的 Git 仓库，用于与其他开发者协作。多个本地仓库可以与远程仓库同步，进行共享和协作。

  • 作用：远程仓库通常用于协作开发，开发者通过 git push 将本地提交推送到远程仓库，也可以通过 git pull 或 git fetch 拉取远程仓库的最新提交。

  • 说明：

    1. 同步：远程仓库的内容可能与本地仓库不同步，或者与本地仓库不同步。远程仓库内容较为“陈旧”，因为它可能未被本地仓库的最新更改覆盖。
    2. 创建远程仓库：你可以在 GitHub、GitLab、Bitbucket 等平台创建远程仓库，并将其链接到本地仓库。

各区域总结

区域作用说明
工作区开发者修改代码的地方文件修改会首先发生在工作区，未被 Git 追踪或提交。
暂存区存储已加入暂存的更改使用 git add 将文件从工作区移动到暂存区，准备提交。
本地仓库存储已提交的历史版本只有通过 git commit 提交的更改才会保存在本地仓库中。
远程仓库存储托管在服务器上的版本，供协作使用通过 git push 和 git pull 同步本地仓库与远程仓库的内容。

总结

  • 工作区：你在计算机中实际看到和操作的文件，修改会直接发生在这里。
  • 暂存区：保存了即将提交的文件状态，是提交前的准备区域。
  • 本地仓库：保存了项目的历史版本，记录所有提交。
  • 远程仓库：与他人协作时使用的仓库，存放在远程服务器上。

每个区域在 Git 中都有不同的作用，理解它们之间的关系对于高效使用 Git 至关重要！

image.png

查看暂存区的内容

$ git ls-files

添加和提交文件

在 Git 中，添加和提交文件是管理版本控制的核心操作。以下是简化和优化后的步骤：

1. 添加文件到暂存区

git add 命令用于将文件添加到 暂存区。暂存区记录了所有即将被提交的变更。

$ git add file1.txt
  • 作用：将 file1.txt 文件的修改添加到暂存区，准备提交。
  • 注意：git add 不会将文件直接提交到本地仓库，它只是将文件的当前状态放入暂存区。

2. 提交文件到本地仓库

使用 git commit 命令将暂存区的文件提交到 本地仓库。

$ git commit -m "commit 1"
  • 作用：将暂存区的所有变更记录为一个新的提交，并附上提交信息 "commit 1"。
  • 说明：-m 选项后跟的是提交信息，用于描述这次提交的目的或内容。

3. 查看提交日志

你可以使用 git log 命令查看提交历史记录：

$ git log
  • 作用：显示详细的提交历史，包括提交的哈希值、作者、时间和提交信息。

4. 简化日志显示

为了更简洁地查看提交记录，可以使用 --oneline 参数，只显示每个提交的简短哈希值和提交信息：

$ git log --oneline
  • 作用：简化提交日志的输出，使其更加简洁，只显示提交的简短哈希和简短的提交信息。
  • 说明：--oneline 是 git log 的一个常用选项，适用于查看简洁的提交历史。

总结：操作流程

  1. 添加文件到暂存区：

    $ git add <file>   # 将修改加入暂存区，准备提交

  2. 提交文件到本地仓库：

    $ git commit -m "commit message"  # 提交暂存区的变更到本地仓库

  3. 查看提交记录：

    $ git log           # 查看详细提交记录
$ git log --oneline # 查看简洁的提交记录

这样，你就可以高效地将修改添加到暂存区、提交到本地仓库，并快速查看提交历史了！

git reset 回退版本

git reset 用于将当前分支回退到指定提交，同时控制 工作区 和 暂存区 的状态。

1. git reset --soft（仅回退提交，不影响工作区和暂存区）

git reset --soft <commit>
  • 提交记录会被回退，但 暂存区和工作区的文件仍保持不变。
  • 适用于 撤销最近的提交，但保留更改，可以重新提交。

📌 适用场景：
当你 误提交 (git commit) ，但还想保留文件以进行修改或重新提交时。

2. git reset --mixed（回退提交，并清空暂存区）

git reset --mixed <commit>
  • 提交记录和暂存区都会被回退，但 工作区的文件不受影响。
  • 适用于 撤销提交，并让文件回到未暂存状态 (git add . 之前的状态) 。

📌 适用场景：
当你提交 (git commit) 了，但想 重新调整暂存的文件，然后再提交时。

（⚠️ git reset --mixed 是默认行为，省略 --soft 或 --hard 时即默认执行 --mixed。）

3. git reset --hard（彻底回退，工作区和暂存区全部清空）

git reset --hard <commit>
  • 提交记录、暂存区和工作区的文件都会被回退，所有未提交的修改都会被丢弃！
  • 适用于 彻底放弃所有改动，恢复到指定版本。

📌 适用场景：
当你想 完全撤销所有更改，恢复到某个稳定版本时。

⚠ 重要提醒：
此操作 不可逆，请慎重使用！如果需要找回数据，可以尝试 git reflog 查看最近的提交历史。

如何查看提交记录？

在执行 git reset 之前，建议先查看提交历史，获取 commit 哈希值。

git log --oneline

示例输出：

c470d35 Fix login bug
fe6fd66 Add user profile page
b3a92d1 Initial commit

然后，使用 git reset --soft fe6fd66 等命令进行回退。

总结

命令影响提交记录影响暂存区影响工作区适用场景
git reset --soft <commit>✅ 回退提交❌ 保持暂存❌ 保持工作区仅撤销提交但保留文件，重新提交
git reset --mixed <commit>✅ 回退提交✅ 清空暂存❌ 保持工作区重新调整暂存的文件
git reset --hard <commit>✅ 回退提交✅ 清空暂存✅ 清空工作区彻底放弃所有改动

💡 推荐做法

  • 谨慎使用 git reset --hard，以免丢失数据！
  • 如果只是想 撤销提交但保留更改，用 git reset --soft。
  • 如果想 撤销提交并重新调整暂存文件，用 git reset --mixed。

这样优化后，结构更清晰，更容易理解不同 git reset 选项的作用。

image.png

查看差异

git diff（工作区与暂存区对比）
bash
复制编辑
$ git diff

查看 工作区 和 暂存区 之间的差异。如果没有输出，则表示两者内容相同。

git diff HEAD（工作区与版本库对比）
bash
复制编辑
$ git diff HEAD

对比 工作区 和 最新提交（HEAD） 之间的差异，适用于未暂存的更改。

git diff --cached（暂存区与版本库对比）
bash
复制编辑
$ git diff --cached

对比 暂存区 和 最新提交（HEAD） 之间的差异，适用于已暂存但尚未提交的更改。

git diff <commit1> <commit2>（任意两个提交版本对比）
bash
复制编辑
$ git diff fe6fd66 c470d35

对比两个指定提交 fe6fd66 和 c470d35 之间的差异。

git diff HEAD~ HEAD（当前版本与上一个版本对比）
bash
复制编辑
$ git diff HEAD~ HEAD

或

bash
复制编辑
$ git diff HEAD^ HEAD

对比当前版本 HEAD 与上一个提交 HEAD~ 之间的变更。

git diff HEAD~2 HEAD（当前版本与上上个版本对比）
bash
复制编辑
$ git diff HEAD~2 HEAD

对比当前版本 HEAD 和 两次提交之前的版本 HEAD~2 之间的变化。

git diff HEAD~ HEAD <file>（指定文件的变更）
bash
复制编辑
$ git diff HEAD~ HEAD file3.txt

仅查看 file3.txt 在 HEAD~ 和 HEAD 之间的变更。

总结

命令对比对象适用场景
git diff工作区 vs 暂存区查看未暂存的修改
git diff HEAD工作区 vs 最新提交检查本地修改
git diff --cached暂存区 vs 最新提交查看已暂存但未提交的更改
git diff <commit1> <commit2>两个指定提交版本历史比对
git diff HEAD~ HEAD上一个版本 vs 当前版本最近变更回顾
git diff HEAD~2 HEAD上上个版本 vs 当前版本进一步回溯更改
git diff HEAD~ HEAD <file>指定文件的变更关注特定文件变动

这样优化后，结构更清晰，易于查找和理解。

从版本库中删除文件

在 Git 中删除文件可以通过两种方式实现，分别是手动删除并更新暂存区，或者使用 Git 提供的命令来直接删除文件并同步更新。

方法 1：手动删除文件

1. 删除文件

首先，你可以手动删除文件，如：

$ rm file4.txt
  • 效果：文件在工作区中被删除，但 Git 的暂存区并未更新，暂存区中依然包含删除前的文件。
2. 更新暂存区

为了同步删除操作，你需要使用 git add . 更新暂存区：

$ git add .
  • 效果：将删除操作从工作区同步到暂存区，Git 会记录下文件删除的变更。

方法 2：使用 git rm 删除文件（推荐）

Git 提供了 git rm 命令，可以一步到位地删除工作区和暂存区的文件：

$ git rm file2.txt
  • 效果：git rm 会直接删除文件，并自动将删除的变更同步到暂存区，无需额外的 git add . 步骤。

提交更改

无论你使用哪种方法删除文件，都需要提交更改到本地仓库：

$ git commit -m "删除文件 file2.txt"
  • 效果：将删除操作作为一次提交，更新到版本库中。

总结

方法删除工作区文件是否需要 git add .推荐程度
rm file.txt + git add .✅✅⭐⭐⭐
git rm file.txt✅❌⭐⭐⭐⭐⭐
  • 推荐：使用 git rm 是最简单且高效的方式。它会同时更新工作区和暂存区，减少了额外的操作步骤，是更推荐的方法。

使用 .gitignore 忽略文件

在 Git 项目中，有时候我们不希望将某些文件或文件夹添加到版本控制中，比如临时文件、编译生成的文件、IDE 配置文件等。这时，我们可以使用 .gitignore 文件来指定哪些文件不需要被 Git 追踪和提交。

1. .gitignore 文件概述

.gitignore 是一个文本文件，位于 Git 仓库的根目录中，里面列出了需要被忽略的文件和文件夹的模式。Git 会根据 .gitignore 中的规则来忽略对应的文件，不再将其添加到版本库中。

2. 创建 .gitignore 文件

  1. 在 Git 仓库根目录下创建一个名为 .gitignore 的文件（如果没有的话）。
$ touch .gitignore

2. 编辑 .gitignore 文件，列出需要忽略的文件或文件夹规则。

$ nano .gitignore

3. .gitignore 文件语法

.gitignore 文件中的每一行代表一个规则，规则可以使用文件路径、通配符、注释等。以下是一些常见的语法规则：

1. 忽略文件或文件夹

  • 忽略特定文件：

    *.log        # 忽略所有 .log 文件

  • 忽略特定文件夹：

    temp/        # 忽略 temp 文件夹
2. 忽略特定文件类型

  • 忽略所有 .exe 文件：

    *.exe

  • 忽略所有 .class 文件：

    *.class
3. 取消忽略某个文件

在 .gitignore 中，如果你想取消对某个已经被忽略的文件的忽略，可以使用 ! 来指定不忽略的文件。

例如，如果你想忽略 .log 文件，但不希望忽略 debug.log 文件：

*.log
!debug.log
4. 注释

可以在 .gitignore 文件中添加注释，注释行以 # 开头：

# 忽略所有日志文件
*.log
5. 通配符

  • * 匹配任意字符：

    *.tmp   # 忽略所有 .tmp 文件

  • ? 匹配单个字符：

    file?.txt  # 忽略 file1.txt、file2.txt 等

  • **/ 匹配任意级别的子目录：

    **/*.bak   # 忽略所有子目录中的 .bak 文件
6. 忽略特定目录下的文件

可以指定仅在特定目录下忽略某种类型的文件：

build/*.log  # 仅忽略 build 目录下的 .log 文件

4. 常见的 .gitignore 文件示例

  • Node.js 项目

    node_modules/
npm-debug.log
yarn-debug.log
yarn-error.log

  • Python 项目

    __pycache__/
*.py[cod]
*.pyo
*.pyd

  • Java 项目

    *.class
target/
*.log

  • IDE 配置文件

    .idea/
.vscode/
*.sublime-workspace

  • macOS 系统生成的文件

    .DS_Store

  • Windows 系统生成的文件

    Thumbs.db
ehthumbs.db

5. 忽略文件的常见问题

1. 已提交的文件不能通过 .gitignore 忽略

.gitignore 只会忽略未被 Git 跟踪的文件，如果文件已经被 Git 跟踪并提交到版本库中，即使之后将其添加到 .gitignore 中，Git 仍会继续跟踪这些文件。

解决方法：如果你已经提交了需要忽略的文件，需要从 Git 仓库中删除这些文件，然后再将其加入 .gitignore：

$ git rm --cached <file>   # 从 Git 索引中移除文件，但保留工作区中的文件
$ git commit -m "移除不需要的文件"

之后，Git 就会根据 .gitignore 忽略这些文件。

2. .gitignore 文件的优先级
  • 全局 .gitignore：可以在用户根目录下配置全局 .gitignore 文件（例如：~/.gitignore_global），这样就可以在所有项目中统一配置忽略规则。可以使用以下命令配置全局 .gitignore：
$ git config --global core.excludesfile ~/.gitignore_global
  • 项目 .gitignore：位于项目根目录下的 .gitignore 会覆盖全局 .gitignore 的规则，具体规则遵循就近原则。

6. 常见的 Git 忽略文件管理工具

  • gitignore.io: 这个网站可以帮助你生成针对不同编程语言、框架、操作系统的 .gitignore 文件。只需选择相应的技术栈，网站会自动生成适合的忽略规则。

总结

  • .gitignore 是 Git 中非常重要的文件，它帮助我们指定哪些文件和文件夹不需要被版本控制。
  • 常见的忽略文件包括编译生成的文件、日志文件、操作系统和 IDE 自动生成的文件等。
  • 使用 git rm --cached 命令可以从版本库中移除已经被跟踪的文件，并结合 .gitignore 忽略这些文件。

SSH 配置及 Git 仓库克隆文档

1. 配置 SSH 密钥

1.1 创建 .ssh 目录

首先，我们需要确保在本地计算机上存在 SSH 密钥目录 .ssh。可以通过以下步骤创建该目录：

mkdir ~/.ssh

这将会在当前用户的主目录下创建 .ssh 目录。之后，我们可以将 SSH 密钥保存在此目录中。

1.2 生成 SSH 密钥对

接下来，我们将生成一个新的 SSH 密钥对，使用 RSA 算法，密钥长度为 4096 位：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
  • -t rsa：指定密钥类型为 RSA。
  • -b 4096：指定密钥的长度为 4096 位。
  • -C "your_email@example.com"：使用你 Git 账户的电子邮件地址进行标识。

生成密钥时，系统会提示你选择保存密钥的路径。如果你没有特殊要求，可以按回车键使用默认路径（~/.ssh/id_rsa）。

1.3 查看生成的公钥

生成密钥后，可以查看公钥内容：

cat ~/.ssh/id_rsa.pub

公钥内容将显示在终端上，复制该内容准备添加到 Git 服务（如 GitHub 或 GitLab）中。

1.4 将公钥添加到 Git 账户

  • 登录到你的 Git 账户（如 GitHub）。
  • 在 GitHub 上，进入 Settings -> SSH and GPG keys，然后点击 New SSH key。
  • 将复制的公钥粘贴到框中，并为该密钥设置一个名字（例如，My PC），然后点击 Add SSH key。

2. 克隆 Git 仓库

2.1 获取 Git 仓库的 SSH URL

在 GitHub 上，打开你想要克隆的仓库页面，点击 Code 按钮，选择 SSH 链接。例如：

git@github.com:Agarwoodchen/remote-repo.git

复制这个 SSH URL，它是你用来克隆仓库的地址。

2.2 使用 SSH 克隆仓库

在命令行中，进入你希望将仓库克隆到的目录，例如：

cd ~/Desktop/remote

然后，运行以下命令来克隆仓库：

git clone git@github.com:Agarwoodchen/remote-repo.git

这将会使用 SSH 协议克隆 remote-repo 仓库到当前目录。

2.3 确认仓库克隆成功

执行克隆命令后，你会看到类似以下的输出：

Cloning into 'remote-repo'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 100 (delta 50), reused 100 (delta 50), pack-reused 0
Receiving objects: 100% (100/100), 12.34 MiB | 1.00 MiB/s, done.
Resolving deltas: 100% (50/50), done.

仓库将被克隆到 ~/Desktop/remote/remote-repo 目录下。

3. 推送更改到远程仓库

3.1 修改文件并添加到 Git

假设你对仓库中的文件进行了更改。首先，使用以下命令查看仓库状态，确保文件已被修改：

git status

然后，使用以下命令将更改添加到暂存区：

git add .

3.2 提交更改

添加文件后，使用以下命令提交更改，并添加提交信息：

git commit -m "Describe your changes"

3.3 推送更改到远程仓库

最后，将更改推送到远程仓库。使用以下命令：

git push

如果一切顺利，你的更改将被推送到远程仓库。

4. 验证 SSH 配置

为了确保 SSH 配置正确并成功与 Git 服务建立连接，你可以使用以下命令来测试 SSH 连接：

ssh -T git@github.com

如果配置成功，GitHub 将返回类似以下的信息：

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

4.1 解决常见问题

  • Permission denied (publickey) ：如果在推送时遇到该错误，表示 SSH 密钥未被正确识别。你可以确保密钥已添加到 Git 服务中，并且 SSH 代理已正确启动。

  • SSH 代理：如果你需要手动启动 SSH 代理并添加密钥，可以使用以下命令：

    eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

总结

通过以上步骤，你已成功配置 SSH 密钥并能够使用 SSH 协议安全地克隆和推送 Git 仓库。这样，你就可以更高效、安全地进行 Git 操作，无需每次推送时输入用户名和密码。

关联本地仓库和远程仓库

在 Git 中，关联本地仓库与远程仓库是一个非常常见的操作。这允许你将本地的更改推送到远程仓库，或者从远程仓库拉取最新的更改。本文将介绍如何将本地仓库与 GitHub（或其他 Git 服务）上的远程仓库进行关联，并执行基本的推送和拉取操作。

1. 关联本地仓库与远程仓库

1.1 初始化本地仓库

如果你还没有初始化本地仓库，可以使用以下命令：

git init

这将会在当前目录下初始化一个新的 Git 仓库。

1.2 查看本地仓库文件

在本地仓库中，我们可以查看当前目录下的文件，确保你已正确初始化仓库。

ls

输出可能显示类似以下内容：

file1.txt  file2.txt  learn-git/  repo/

这些文件和目录是你本地仓库的一部分。

1.3 关联远程仓库

通过以下命令将本地仓库与远程仓库关联。此命令将远程仓库的地址（例如 GitHub 上的仓库地址）添加为 origin。

git remote add origin git@github.com:Agarwoodchen/first-repo.git
  • git remote add origin：此命令添加一个名为 origin 的远程仓库。
  • git@github.com:Agarwoodchen/first-repo.git：这是你在 GitHub 上创建的远程仓库的 SSH 地址。请确保你使用的是 SSH 地址（而不是 HTTPS 地址），这样你就不需要每次输入用户名和密码。

1.4 验证远程仓库

运行以下命令检查已添加的远程仓库：

git remote -v

你应该看到类似以下的输出：

origin  git@github.com:Agarwoodchen/first-repo.git (fetch)
origin  git@github.com:Agarwoodchen/first-repo.git (push)

此输出表明，远程仓库 origin 已成功添加并关联。

2. 推送本地代码到远程仓库

2.1 查看当前分支

执行以下命令，查看当前所在的分支：

git branch

输出可能类似于：

* master

这意味着你当前在 master 分支上。

2.2 推送本地代码到远程仓库

将本地仓库的代码推送到远程仓库，你可以使用以下命令：

git push -u origin master
  • git push：将本地代码推送到远程仓库。
  • -u：表示设置上游分支。也就是说，未来的 git push 或 git pull 命令将默认与 origin master 关联。
  • origin：远程仓库的名字。
  • master：本地分支的名字。此命令将本地 master 分支的内容推送到远程 origin 仓库的 master 分支。

执行命令后，如果一切顺利，你将看到推送成功的消息。

2.3 推送后的输出

推送成功后，终端会显示类似以下的输出：

Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (5/5), 549 bytes | 549.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0)
To git@github.com:Agarwoodchen/first-repo.git
 * [new branch]      master -> master

这意味着本地的 master 分支已经成功推送到远程仓库的 master 分支。

3. 从远程仓库拉取更改

3.1 拉取远程仓库的最新更改

为了确保本地仓库与远程仓库保持同步，你可以定期使用以下命令从远程仓库拉取最新的更改：

git pull

此命令将从远程仓库（默认为 origin）拉取最新的更改，并与本地的当前分支合并。

3.2 合并冲突

如果在 git pull 时出现合并冲突，Git 会提示你解决冲突。你可以手动编辑冲突文件并选择接受的更改。完成后，执行以下命令标记冲突为已解决：

git add <conflicted-file>
git commit

然后，你可以再次推送更改到远程仓库。

4. 验证远程仓库状态

4.1 查看当前仓库的所有远程仓库

如果你有多个远程仓库，可以使用以下命令查看所有配置的远程仓库：

git remote -v

4.2 查看远程仓库的详细信息

如果你需要查看远程仓库的更多信息，可以使用：

git remote show origin

此命令将显示关于远程仓库 origin 的详细信息，包括它的 URL、分支信息和推送/拉取权限等。

总结

通过以上步骤，你成功地将本地 Git 仓库与远程 Git 仓库关联，并能够进行基本的推送（git push）和拉取（git pull）操作。这是与 GitHub 或其他 Git 服务协作的基础。

常用命令总结：

  • git remote add origin <url>：关联远程仓库。
  • git remote -v：查看远程仓库信息。
  • git push -u origin <branch>：推送本地分支到远程仓库，并设置默认上游分支。
  • git pull：拉取远程仓库的最新更改并合并。

Git 提交与推送到 Gitee 的完整流程

本教程将指导你如何创建 Git 仓库、提交文件、关联远程仓库，并将代码推送到 Gitee 仓库。

1. 初始化本地仓库并添加文件

1.1 创建文件

在本地仓库中创建一个文件（如 README.md）：

touch README.md

此命令将在当前目录下创建一个空的 README.md 文件。你可以用任何文本编辑器打开并编辑它，或者直接在终端中添加一些内容。

1.2 查看当前仓库状态

运行 git status 查看仓库的当前状态：

git status

输出类似于：

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

这意味着你有一个未跟踪的文件 README.md，它还没有被加入到 Git 的暂存区。

1.3 将文件添加到暂存区

使用 git add . 将所有新文件（包括 README.md）添加到暂存区：

git add .

运行 git status，你会看到文件已被加入到暂存区：

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

1.4 提交文件到本地仓库

执行提交操作，将 README.md 文件提交到本地 Git 仓库：

git commit -m "first commit"

提交完成后，使用 git status 检查仓库状态：

git status

输出类似于：

On branch master
nothing to commit, working tree clean

说明所有更改已经提交，工作区干净。

2. 关联远程仓库并推送代码

2.1 关联远程仓库

你可以通过以下命令将本地仓库与 Gitee 仓库关联。使用 HTTPS 协议 的命令如下：

git remote add origin https://gitee.com/username/first-repo.git

如果你遇到 remote origin already exists 错误，说明远程仓库已经存在。你可以使用以下命令修改远程仓库 URL：

git remote set-url origin https://gitee.com/username/first-repo.git

2.2 推送到 Gitee（HTTPS 错误解决）

你尝试通过 git push 推送代码时遇到 403 Access Denied 错误，这通常是由于认证问题。解决方法如下：

使用 HTTPS 协议时：

  1. 确认用户名和密码：如果你使用的是 HTTPS，确保输入了正确的 Gitee 用户名和密码。

  2. 使用访问令牌：如果启用了两步验证，无法使用普通密码进行认证。在这种情况下，你需要生成一个 Personal Access Token，并将其用作密码。

    • 生成访问令牌：

      • 访问 Gitee 个人设置 > 安全设置 > 访问令牌，生成一个新的访问令牌。

    • 在推送时，使用该访问令牌作为密码。

使用 SSH 协议：

  1. 设置 SSH 密钥：如果你更倾向于使用 SSH 协议，首先确保你的 SSH 密钥已正确配置并添加到 Gitee。

  2. 修改远程仓库为 SSH 地址：

    git remote set-url origin git@gitee.com:username/first-repo.git

  3. 推送到远程仓库：如果配置了 SSH 密钥，执行以下命令推送代码：

    git push -u origin master

    初次连接 Gitee 时，系统会提示你确认 Gitee 的 SSH 密钥指纹，输入 yes 继续。

    你会看到如下输出：

    The authenticity of host 'gitee.com (180.76.199.13)' can't be established.
ED25519 key fingerprint is SHA256:+ULzij2u99B9eWYFTw1Q4ErYG/aepHLbu96PAUCoV88.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'gitee.com' (ED25519) to the list of known hosts.

  4. 输入 SSH 密钥的密码：如果你的 SSH 密钥有密码，系统会提示你输入密码。

    如果一切顺利，推送成功并设置上游分支：

    To gitee.com:username/first-repo.git
 * [new branch]      master -> master
branch 'master' set up to track 'origin/master'.

2.3 远程仓库验证

推送完成后，使用以下命令检查远程仓库配置：

git remote -v

输出应该类似于：

origin  git@gitee.com:username/first-repo.git (fetch)
origin  git@gitee.com:username/first-repo.git (push)

这表示远程仓库 origin 已成功配置为 Gitee 仓库。

3. 常见问题与解决

3.1 403 Access Denied 错误

  • 原因：认证失败或没有权限推送。

  • 解决方法：

    • 如果使用 HTTPS，确保使用访问令牌，而不是密码。
    • 如果使用 SSH，确保 SSH 密钥已正确配置并添加到 Gitee。
    • 检查是否有权限推送到该仓库，确保你是该仓库的所有者或协作者。

3.2 remote origin already exists 错误

  • 原因：你尝试添加相同的远程仓库 URL。
  • 解决方法：使用 git remote set-url 更新远程仓库 URL。

总结

通过以上步骤，你成功地创建了一个本地仓库，提交了文件，并将代码推送到 Gitee。解决 403 Access Denied 错误的方法是确保正确配置认证方式，可以选择使用 HTTPS 访问令牌或 SSH 密钥。通过这些操作，你可以高效地与远程仓库进行交互并保持同步。

注意：在实际操作过程中，确保不要泄露你的访问令牌、SSH 密钥和远程仓库 URL。如果是公共文档或共享代码时，应尽量隐去这些敏感信息，避免安全风险。

如何将本地 Git 仓库关联到已有的 Gitee 仓库

1. 前提条件

  • 确保你已经在本地初始化了一个 Git 仓库。
  • 确保你已经拥有一个 已有的 Gitee 仓库，并且能够访问它。
  • 了解 Gitee 仓库的 SSH 或 HTTPS 地址。

2. 获取远程 Gitee 仓库的 URL

首先，你需要获取 Gitee 仓库的远程 URL。Gitee 提供了两种访问仓库的协议：HTTPS 和 SSH。

  • HTTPS 地址：这种方式适用于不使用 SSH 密钥的情况，每次推送时需要输入 Gitee 用户名和密码。

    • 示例：https://gitee.com/username/your-repo.git

  • SSH 地址：这种方式适用于使用 SSH 密钥的情况，不需要每次输入用户名和密码。

    • 示例：git@gitee.com:username/your-repo.git

你可以在 Gitee 仓库页面上找到仓库的 URL，点击 克隆/下载 按钮，选择适合的协议复制 URL。

3. 将本地仓库关联到 Gitee 仓库

3.1 进入本地仓库目录

首先，进入你本地的 Git 仓库目录：

cd /path/to/your/local/repo

3.2 添加远程仓库 URL

接下来，运行以下命令将 Gitee 仓库的 URL 关联到本地仓库：

3.2.1 使用 HTTPS 协议

如果你使用 HTTPS 协议来连接 Gitee，运行以下命令：

git remote add origin https://gitee.com/username/your-repo.git
3.2.2 使用 SSH 协议

如果你使用 SSH 协议来连接 Gitee，运行以下命令：

git remote add origin git@gitee.com:username/your-repo.git

3.3 验证远程仓库配置

运行以下命令，检查远程仓库是否成功关联：

git remote -v

输出应该类似于：

origin  https://gitee.com/username/your-repo.git (fetch)
origin  https://gitee.com/username/your-repo.git (push)

或者，如果你使用了 SSH 协议，输出应该是：

origin  git@gitee.com:username/your-repo.git (fetch)
origin  git@gitee.com:username/your-repo.git (push)

这表示你的本地仓库已经成功关联到了 Gitee 仓库。

4. 提交和推送代码到 Gitee

4.1 提交本地更改

如果你本地有更改（如新建文件、修改文件等），你需要先将这些更改提交到本地仓库：

git add .
git commit -m "Your commit message"

4.2 推送到 Gitee

将你的本地代码推送到 Gitee 上的远程仓库：

git push -u origin master
  • -u 选项将本地的 master 分支与远程仓库的 master 分支关联，之后你可以只使用 git push 推送更改。

4.3 输入认证信息

  • HTTPS 协议：如果你使用 HTTPS 协议，系统会提示你输入 Gitee 用户名和密码。如果启用了两步验证，你需要使用 访问令牌 作为密码。
  • SSH 协议：如果你使用 SSH 协议，系统会提示你输入 SSH 密钥的密码（如果你为 SSH 密钥设置了密码）。

4.4 验证推送结果

推送成功后，终端输出会显示类似以下内容：

To gitee.com:username/your-repo.git
 * [new branch]      master -> master
branch 'master' set up to track 'origin/master'.

这表示你成功将本地仓库的代码推送到了 Gitee 上，并且将本地的 master 分支与远程的 master 分支关联。

5. 常见问题与解决

5.1 远程仓库已经存在（remote origin already exists）

如果你尝试添加远程仓库时遇到如下错误：

error: remote origin already exists.

这说明你的本地仓库已经关联了一个远程仓库。你可以使用 git remote set-url 命令更新现有的远程仓库 URL：

git remote set-url origin https://gitee.com/username/your-repo.git

或者，如果你使用 SSH 协议：

git remote set-url origin git@gitee.com:username/your-repo.git

5.2 推送时遇到 403 Access Denied 错误

403 Access Denied 错误通常是由于认证失败或没有权限推送到仓库。

  • 如果你使用 HTTPS 协议，确保你输入了正确的用户名和密码，或者使用 访问令牌 作为密码。
  • 如果你使用 SSH 协议，确保你已经配置了正确的 SSH 密钥，并将公钥添加到 Gitee。

5.3 如何检查远程仓库配置

如果你想检查或验证远程仓库的详细配置，可以使用以下命令：

git remote show origin

这个命令将显示远程仓库的详细信息，包括仓库的 URL、分支等信息。

6. 总结

通过上述步骤，你可以将本地的 Git 仓库与已有的 Gitee 仓库关联。确保你选择了正确的协议（HTTPS 或 SSH），并根据需要进行身份验证。一旦关联成功，你就可以将本地更改推送到远程仓库，并与团队或他人进行协作。

如果遇到问题，请检查远程仓库 URL 是否正确，或者确认认证信息（用户名、密码或 SSH 密钥）是否正确。

Git 分支使用指南

Git 分支是版本控制系统中的一个非常强大的功能，它允许你在不影响主代码（通常是 master 或 main 分支）的情况下，创建一个独立的开发环境来进行修改、测试和功能开发。分支是 Git 的核心概念之一，它能帮助团队更高效地协作开发。

1. Git 分支概述

1.1 什么是 Git 分支？

在 Git 中，**分支（Branch）**是指代码库中的独立线（版本）的副本，可以进行修改而不会影响其他分支。当你创建一个分支时，Git 会复制当前工作区的所有内容（包括代码文件和提交记录），你可以在该分支上进行独立的开发工作。

1.2 为什么要使用 Git 分支？

  • 独立开发：你可以在分支上开发新功能或修复 bug，而不影响主分支上的代码。
  • 多人协作：分支使得多个开发人员能够并行工作，每个人在自己的分支上工作，避免了代码冲突。
  • 版本控制：通过分支，Git 可以帮助你保留不同开发阶段的历史记录，方便回溯和管理。

1.3 分支的基本操作

Git 提供了多种分支操作，下面是常见的命令：

  • 查看分支：查看当前的所有分支。

    git branch

  • 创建新分支：创建一个新的分支。

    git branch <branch-name>

  • 切换分支：切换到指定的分支。

    git checkout <branch-name>

  • 创建并切换到新分支：创建并立即切换到新分支。

    git checkout -b <branch-name>

  • 删除分支：删除本地分支。

    git branch -d <branch-name>

  • 合并分支：将指定分支合并到当前分支。

    git merge <branch-name>

  • 查看分支图：使用 git log 显示分支的历史记录（带图示）。

    git log --graph --oneline --all

2. Git 分支工作流

2.1 分支工作流示意图

让我们通过一个简单的工作流示意图来理解分支的使用。

假设你有一个项目的主分支 master（或者 main），你想在上面添加新功能或者修复 bug：

   A---B---C---D---E (master)
                \
                 F (new-feature)
  1. master 分支：当前稳定的主分支，包含已发布的代码。
  2. new-feature 分支：这是一个新分支，你在上面开发新功能，不会影响 master 分支的代码。

在 new-feature 分支上完成开发后，你可以将它合并回 master 分支。

2.2 分支操作流程

1. 创建新分支

假设你要从 master 分支开始开发一个新的功能，你首先需要切换到 master 分支，并创建一个新分支。

git checkout master        # 确保你在 master 分支上
git checkout -b new-feature  # 创建并切换到 new-feature 分支

此时的分支结构：

   A---B---C---D---E (master)
                \
                 F (new-feature)
2. 在新分支上进行开发

在 new-feature 分支上开发你的新功能，进行多次提交：

git add .        # 添加修改
git commit -m "Start working on new feature"  # 提交修改

此时的分支结构：

   A---B---C---D---E (master)
                \
                 F---G---H (new-feature)
3. 将新功能合并回主分支

完成开发后，你可以将 new-feature 分支的修改合并到 master 分支：

git checkout master  # 切换到 master 分支
git merge new-feature  # 合并 new-feature 分支

此时的分支结构：

   A---B---C---D---E---I (master)
                \     /
                 F---G---H (new-feature)
4. 删除合并后的分支

合并完成后，可以删除不再需要的 new-feature 分支：

git branch -d new-feature  # 删除本地分支

此时的分支结构：

   A---B---C---D---E---I (master)

3. Git 分支图示

以下是 Git 分支的一些常见操作和结构示意图。

3.1 单一分支开发

最简单的场景就是只有一个分支（master）在开发：

   A---B---C---D---E (master)

3.2 创建新分支进行开发

创建一个新的分支 feature 来开发新功能，原有分支 master 不受影响：

   A---B---C---D---E (master)
                \
                 F (feature)

3.3 分支合并

当 feature 分支开发完成后，它的内容被合并回 master 分支：

   A---B---C---D---E---F (master)
                \     /
                 G---H (feature)

3.4 冲突解决

在某些情况下，分支合并时可能会发生冲突，例如，如果两个分支修改了同一文件的同一部分，Git 无法自动合并，这时需要手动解决冲突。解决后，Git 会保留合并的版本，并让你提交解决冲突后的更改。

   A---B---C---D---E (master)
                \     /
                 F---G (feature)

4. Git 分支工作流推荐

4.1 基本 Git Flow 工作流

在团队协作中，可以采用如下的分支策略：

  • master：生产环境分支，始终保持稳定。
  • develop：开发分支，所有的功能都在 develop 上集成，功能完成后合并到 master。
  • feature/xxx：功能分支，开发某个新功能时，使用 feature 分支。
  • release/xxx：发布分支，准备发布新版本时，从 develop 创建 release 分支。
  • hotfix/xxx：热修复分支，针对生产环境出现的紧急问题，从 master 创建 hotfix 分支。

4.2 Git Flow 工作流示意图

           feature/login        feature/checkout
              |                    |
            [F1]                 [F2]
              |                    |
         develop ----------> release
              |                    |
        bugfix/hotfix            master

5. 总结

  • 分支 是 Git 的强大功能，允许你在多个不同的代码线之间切换，进行并行开发。
  • 使用分支可以 避免冲突，在进行新功能开发时，不影响主代码。
  • 常见的操作有创建分支、切换分支、合并分支、删除分支等。
  • Git 提供了非常直观的 图形化 命令，如 git log --graph，帮助你更清晰地了解分支的变化。

Git 合并冲突解决指南

在 Git 中，合并冲突发生在两个分支尝试合并并修改了同一文件的相同部分时，Git 无法自动决定使用哪一部分内容。此时需要手动干预并解决冲突。理解合并冲突的原理并掌握解决方式是 Git 工作流中一个非常重要的技能。

1. 什么是 Git 合并冲突？

合并冲突发生的原因是 Git 在执行合并操作时，无法自动决定两个分支的修改应该如何合并。冲突通常出现在以下两种情况：

  • 编辑同一行代码：如果两个分支对同一行代码做了不同的修改，Git 无法决定哪一部分修改更合适。
  • 删除文件与修改文件：如果一个分支删除了某个文件，而另一个分支修改了该文件，Git 也无法自动处理这个冲突。

2. 合并冲突的工作流

合并冲突通常出现在执行 git merge 或 git rebase 时。合并时，Git 会尝试自动合并分支，如果发生冲突，它会提示冲突文件，并让你手动解决。

2.1 合并冲突的示例流程

  1. 准备代码库：首先，假设有两个分支：master 和 feature。

    • master 分支：存在一个文件 README.md，内容为 Hello World。
    • feature 分支：在 README.md 文件中修改了内容为 Hello Feature。

  2. 在 master 分支上修改：假设在 master 分支上我们修改了 README.md 文件，将内容更改为 Hello Master。

  3. 在 feature 分支上修改：同时，在 feature 分支上修改了 README.md 文件，将内容更改为 Hello Feature。

  4. 合并时发生冲突： 当我们尝试将 feature 分支合并到 master 时，Git 会检测到冲突，因为 README.md 文件在两个分支上被修改了同一部分。

2.2 合并冲突的具体步骤

  1. 切换到目标分支：你需要先切换到你希望将其他分支合并进来的目标分支。例如，将 feature 合并到 master：

    git checkout master

  2. 执行合并操作：

    git merge feature

  3. 发生冲突： 如果 feature 分支中的 README.md 文件与 master 分支中相同的文件内容发生冲突，Git 会输出类似如下的错误信息：

    Auto-merging README.md
CONFLICT (content): Merge conflict in README.md

  4. 查看冲突文件：此时，冲突发生的文件会被标记为“未合并（unmerged）”状态。你可以使用 git status 查看冲突文件：

    git status

    输出会显示类似下面的信息：

    On branch master
Your branch is up to date with 'origin/master'.
Unmerged paths:
(use "git add <file>..." to mark resolution)
      both modified:   README.md

  5. 解决冲突：打开冲突文件（如 README.md），你会看到 Git 插入的标记，指示冲突的部分。冲突文件通常会显示如下内容：

    <<<<<<< HEAD
Hello Master
=======
Hello Feature
>>>>>>> feature
    • <<<<<<< HEAD 表示当前 master 分支的内容。
    • ======= 是分隔符。
    • >>>>>>> feature 是 feature 分支的内容。

    你需要手动修改这个文件，选择适当的内容。比如，如果你想将两个分支的修改都保留，可以像这样更新文件：

    Hello Master and Feature

    或者选择其中一个分支的修改。

  6. 标记为已解决并提交：当你解决了冲突后，保存文件并标记为已解决。使用以下命令：

    git add README.md

    然后提交合并：

    git commit

    Git 会自动生成一个提交信息，表明这是一次合并提交。如果你需要自定义提交信息，可以在命令中加上 -m 选项：

    git commit -m "Resolved merge conflict in README.md"

  7. 推送更改：如果你正在与远程仓库协作，推送解决冲突后的更改：

    git push origin master

3. 解决合并冲突的最佳实践

3.1 小步提交，频繁合并

  • 保持分支更新，定期从 master 分支拉取最新的代码，并将其合并到你的功能分支，减少冲突的可能性。

    git checkout feature
git merge master

3.2 使用 Git GUI 工具

如果你不喜欢手动处理冲突标记，可以使用 Git GUI 工具，如 Sourcetree 或 GitKraken，它们提供可视化的冲突解决工具，帮助你更轻松地解决冲突。

3.3 避免长时间开发在分支上

长时间没有合并的分支，合并时冲突会非常复杂，建议在功能开发完毕后尽快合并。

3.4 保持良好的团队协作

确保团队成员之间进行有效的沟通，尽量避免在同一文件的相同部分进行修改。使用小步提交，确保开发中的代码保持最新。

4. 合并冲突的常见问题

4.1 冲突文件如何解决？

冲突发生后，Git 会在文件中插入标记，通常是：

<<<<<<< HEAD
（当前分支的内容）
=======
（目标分支的内容）
>>>>>>> (目标分支名)

你需要手动解决这些冲突，选择保留哪一部分内容，或者合并两者内容。

4.2 如何避免合并冲突？

  • 频繁合并：经常从主分支合并到你的功能分支，保持你的分支更新。
  • 小步提交：不要一次性提交大量的改动，分成多个小的提交进行提交和合并。
  • 良好的沟通：团队成员之间应避免在相同文件的同一部分做修改。

4.3 冲突解决后，如何确认？

冲突解决后，可以使用 git status 命令确认冲突已解决，并且文件已准备好提交。

git status

如果显示 all conflicts fixed，并且你已将文件标记为已解决，那么就可以提交更改了。

4.4 如何查看历史合并记录？

使用以下命令查看合并历史：

git log --merges

5. 总结

  • Git 合并冲突 是开发中不可避免的一部分，理解如何正确解决冲突对于团队协作至关重要。
  • 解决冲突 时，你需要手动检查冲突的文件，选择保留哪一部分内容，并最终提交合并。
  • 避免冲突的最佳做法 是经常将分支更新为最新，进行小步提交，并保持团队间的有效沟通。
avatar
文章
阅读
粉丝