git 使用

1. git 使用

1.1. 配置代理

1.1.1. 全局配置

推荐这种, 方便可控。

export HTTP_PROXY=127.0.0.1:1087
export HTTPS_PROXY=127.0.0.1:1087

如果想要清除:

unset HTTP_PROXY
unset HTTPS_PROXY

1.1.2. 仅适于 git 配置

git config --global http.proxy http://127.0.0.1:1087
git config --global https.proxy https://127.0.0.1:1087

# Method 1. git http + proxy http
git config --global http.proxy "http://127.0.0.1:1080"
git config --global https.proxy "http://127.0.0.1:1080"

# Method 2. git http + proxy shocks
git config --global http.proxy "socks5://127.0.0.1:1080"
git config --global https.proxy "socks5://127.0.0.1:1080"

# to unset
git config --global --unset http.proxy
git config --global --unset https.proxy

# Method 3. git ssh + proxy http
vim ~/.ssh/config
Host github.com
HostName github.com
User git
ProxyCommand socat - PROXY:127.0.0.1:%h:%p,proxyport=1087

# Method 4. git ssh + proxy socks
vim ~/.ssh/config
Host github.com
HostName github.com
User git
ProxyCommand nc -v -x 127.0.0.1:1080 %h %p

1.2. tag

1.2.1. checkout tag

其实切换 tag 和切换 branch 是一样的:

git branch -a
git checkout master

git tag
  v0.2.1
  ...
git checkout v0.2.1

1.2.2. git tag

$ git tag v1.0
$ git push origin v1.0

# push 所有 tag
git push --tags
# 或
git push origin --tags

为 commit ID 打 tag:

$ git tag v0.9 471fd27

查看标签:

$ git tag
tag_20170908
tag_20170914
v0.9
v1.o

# 查看本地
`git tag -l`

# 查看远程
`git show-ref --tag`

删除:

# 删除本地 tag
git tag -d v1.0.0

# 删除远程 tag
git push origin :refs/tags/v1.0.0

1.3. 检查 gitignore 触发了哪条规则

用于知道为什么文件被忽略掉了:

git check-ignore -v --no-index path/to/check

git check-ignore -v path/to/check

More info at man git-check-ignore.

1.4. git 区分文件名大小写

在部分操作系统下, 如 Windows 和 MacOS, 是不区分文件名大小写的, 此时 git 也会跟随系统, 如果想强制 git 区分大小写的话, 可以使用以下命令:

git mv app.js App.js

1.5. 让 git 忽略文件模式的改变

使用 git 的过程中发现, 就算文件的内容没改变, 只有文件的权限改变的话, git 也会检测到文件被修改了。

解决方法是配置一下:

git config --global core.filemode false

有些时候, 你发现这样配置之后没有什么效果, 那是因为该容器内还有自己的配置信息, 这个配置信息会覆盖 global 的配置, 那么就需要对该容器做一下配置:

git config core.filemode false

这样 git 就会忽略文件模式的改变了。

1.6. 每一行文本的末尾都有额外的 ^M 字符

我需要用到必需在 Windows 系统上创建的文本文件。因为这些文本只能由 Windows 系统上的 Microsoft Acesss 软件生成。

然后, 我用这些新生成文本文件覆盖旧有的文本文件。我用 git diff 查看覆盖后的差异。

git diff

结果如下:

+BBB*^M
+AAA*^M
+YYY*^M
+XXX*^M

可以看到, 增加的每一行文本的末尾都有额外的 ^M 字符。

但是用 vim 打开相应的文本文件, 使用搜索命令

/\^M

并没有找到 ^M 字样

E486: Pattern not found: ^M

那么, 为什么 git diff 查看到差异与用 vim 看到字符不一致呢?

首先, 你要了解 line break types, 我引用其中一个回答:

This is a good summary I found:

The Carriage Return (CR) character (0x0D, \r) moves the cursor to the beginning of the line without advancing to the next line. This character is used as a new line character in Commodore and Early Macintosh operating systems (OS-9 and earlier).
The Line Feed (LF) character (0x0A, \n) moves the cursor down to the next line without returning to the beginning of the line. This character is used as a new line character in UNIX based systems (Linux, Mac OSX, etc)
The End of Line (EOL) sequence (0x0D 0x0A, \r\n) is actually two ASCII characters, a combination of the CR and LF characters. It moves the cursor both down to the next line and to the beginning of that line. This character is used as a new line character in most other non-Unix operating systems including Microsoft Windows, Symbian OS and others.

简单概括下: windows 的文本默认以 \r 作为一行的结束, 类 UNIX 系统, 包括 macOS, 的文本默认以 \r\n 作为一行的结束。

行末多出的 ^M 字符正是出于这个原因:

In ASCII and Unicode, the carriage return is defined as 13 (or hexadecimal 0D); it may also be seen as control+M or ^M.

1.6.1. Solution

所以解决方案就呼之欲出了 .git 需要知道 ^M 也是换行符的一部分。

git config --global core.whitespace cr-at-eol

This basically tells Git that an end-of-line CR is not an error.
As a result, those annoying ^M characters no longer appear at the end of lines in git diff, git show, etc.

详细解释下为什么这个 gitconfig 可行, 详见 此处

Git comes preset to detect and fix some whitespace issues. … and cr-at-eol, which tells Git that carriage returns at the end of lines are OK.

1.7. could not read Username for xxx

出现这样的一般是鉴权失败造成的, 看 URL 是否正确:

$ vi ~/.gitconfig

[url "ssh://git@gitlab.xxx.com:10033/"]
  insteadOf = http://gitlab.xxx.com/

1.8. could not read Username … terminal prompts disabled

问题描述:

初始化 go 项目加载 go.mod 时, 报错误提示:

fatal: could not read Username ... terminal prompts disabled

问题定位:

由于加载 go.mod 使用的是 go get 命令, 其中 go get 命令用于从远程代码仓库(比如 Github ) 上下载并安装代码包, 由于使用的是内网的仓库的依赖包, 所以猜测可能是没有配置 git config 相关的配置

通过命令 git config --list 或 vi ~/.gitconfig 查看 git 的配置信息

$ git config --list  

        user.name=test

        user.email=test@gmail.com

        .....          

解决方案:

添加用户名或密码配置或修改为 ssh 访问仓库

1. 修改配置文件 ～/.gitconfig, 添加配置信息

[user]
# Please adapt and uncomment the following lines:
    name = test
    email = test@gmail.com  

[url "ssh://git@github.com:"]
    insteadOf = https://github.com/

2. 直接使用 git config 配置

git config --global user.name "test"  
git config --global user.email test@gmail.com  
git config --global --add url."git@github.com:".insteadOf "https://github.com/"

3. 修改 GIT_TERMINAL_PROMPT 配置

export GIT_TERMINAL_PROMPT=1

1.9. 无法删除 git 远程分支的问题: the next ‘git clone’ won’t result in any file checked out, causing confusion

原因好像是因为 HEAD 指向了要删除的分支。

解决方法有两个:

1. 修改 HEAD 的指向 (推荐): 在 admin 里面将 “默认分支” 改成其它的分支。例如 gitee 需要登录后台管理。
2. 修改 git 的配置 (不推荐): git config receive.denyDeleteCurrent false。

1.10. error: cannot lock ref ‘refs/tags/xxx’: ‘refs/tags/’ exists

> git pull
error: cannot lock ref 'refs/tags/v2.8': 'refs/tags' exists; cannot create 'refs/tags/v2.8'
From github.com:k3it/qsorder
 ! [new tag]         v2.8       -> v2.8  (unable to update local ref)
error: cannot lock ref 'refs/tags/v2.9': 'refs/tags' exists; cannot create 'refs/tags/v2.9'
 ! [new tag]         v2.9       -> v2.9  (unable to update local ref)

solution:

• git update-ref -d refs/tags

Update local repository:
Once the branch is removed, we need to update the local repository. Otherwise, the branch still remains in our repository. We need to remove branches that are no longer in the remote repository. Execute the following command. It removes all branches from the local repository that have gone from the remote repository.

git fetch --prune

1.11. 如何清除 git 仓库的所有提交记录, 成为一个新的干净仓库

git checkout --orphan latest_branch

2. git 清理

2.1. Git 历史清理

在本文中, 我们将介绍如何从 Git 仓库中删除旧的提交信息以节省空间 .git 是一种分布式版本控制系统, 可以追踪文件的变化并保存每个提交的信息。然而, 随着项目的发展, 仓库中的提交信息可能会变得庞大, 占用大量空间。因此, 删除旧的提交信息可以有效地节省存储空间和提高仓库的性能。

Git 提供了几种方法来清理旧的提交信息。下面是一些常用的方法:

2.1.1. Git 重新初始化

一种简单的方法是重新初始化 Git 仓库, 将旧的提交信息完全删除。这种方法会丢失所有历史记录, 只保留当前的代码状态。可以通过以下命令来重新初始化仓库:

git init

注意, 在执行该命令前, 请备份 Git 仓库的内容, 以免不可挽回地丢失历史记录。

2.1.2. 使用 Git 重写历史

Git 提供了一些命令来修改和重写提交历史。这些命令可以用于删除旧的提交信息。下面是一些常见的命令示例:

• git rebase -i <commit>: 可以交互式地重新制作提交历史。通过选择要删除的提交, 可以删除旧的提交信息。例如, 可以使用以下命令来进行交互式的 rebase 操作:

  git rebase -i HEAD~3

  这将打开一个编辑器, 显示最近的 3 个提交。通过删除或标记为"drop"来删除不需要的提交信息, 然后保存并退出编辑器。

- `git filter-branch`: 可以使用`filter-branch`命令来过滤提交历史并删除特定的提交信息。例如, 以下命令将删除一个名为"old-commit"的提交: 

  git filter-branch --commit-filter 'if [ "GIT_COMMITTER_NAME" = "old-commit" ];
  then skip_commit "@";
  else git commit-tree "$@";
  fi' HEAD

- `git cherry-pick`: 可以使用`cherry-pick`命令选择性地合并提交信息。可以选择要保留或删除的提交信息, 并将它们合并到新的分支或提交中。

上述命令可以根据需要进行组合使用, 以达到清理旧的提交信息的目的。但是请注意, 在进行这些操作之前, 请备份 Git 仓库以防止意外数据丢失。

# 示例说明

假设我们有一个 Git 仓库包含了过去一年的提交历史, 并且由于提交信息较多, 导致该仓库占用了大量空间。我们希望删除过去 6 个月的提交信息。

首先, 我们可以使用 git log 命令查看最近的提交历史: 

git log

然后, 我们可以使用 git rebase -i 命令来交互式地重新制作提交历史, 并删除不需要的提交信息。假设我们要删除过去 6 个月的提交信息, 我们可以运行以下命令:

git rebase -i HEAD~6

该命令会打开一个编辑器, 显示最近的 6 个提交。通过删除或标记为"drop"来删除不需要的提交信息, 然后保存并退出编辑器。

完成交互式 rebase 后, 我们可以使用 git log 命令再次查看提交历史, 确认已成功删除了旧的提交信息。

2.2. Git 如何永久删除文件(包括历史记录)

有些时候不小心上传了一些敏感文件(例如密码), 或者不想上传的文件(没及时或忘了加到 .gitignore 里的),

而且上传的文件又特别大的时候, 这将导致别人 clone 你的代码或下载 zip 包的时候也必须更新或下载这些无用的文件,

因此, 我们需要一个方法, 永久的删除这些文件(包括该文件的历史记录).

首先, 可以参考 github 的帮助:

https://help.github.com/articles/remove-sensitive-data

2.2.1. 步骤一: 从你的资料库中清除文件

以 Windows 下为例 (Linux 类似), 打开项目的 Git Bash, 使用命令:

$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch path-to-your-remove-file' --prune-empty --tag-name-filter cat -- --all

其中, path-to-your-remove-file 就是你要删除的文件的相对路径(相对于 git 仓库的跟目录), 替换成你要删除的文件即可。注意一点, 这里的文件或文件夹, 都不能以 ‘/’ 开头, 否则文件或文件夹会被认为是从 git 的安装目录开始。

如果你要删除的目标不是文件, 而是文件夹, 那么请在 git rm --cached' 命令后面添加 -r 命令, 表示递归的删除(子)文件夹和文件夹下的文件, 类似于 rm -rf` 命令。

此外, 如果你要删除的文件很多, 可以写进一个。sh 文件批量执行, 如果文件或路径里有中文, 由于 MinGW 或 CygWin 对中文路径设置比较麻烦, 你可以使用通配符号, 例如: sound/music_.mp3, 这样就把 sound 目录下以 music_开头的 mp3 文件都删除了。

例如这样, 新建一个 bash 脚本文件, del-music-mp3.sh:

#!/bin/bash

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch projects/Moon.mp3' --prune-empty --tag-name-filter cat -- --all
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch sound/Music_*.mp3' --prune-empty --tag-name-filter cat -- --all

如果你看到类似下面这样的, 就说明删除成功了:

Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (266/266)
# Ref 'refs/heads/master' was rewritten

如果显示 xxxxx unchanged, 说明 repo 里没有找到该文件, 请检查路径和文件名是否正确。

注意: 补充一点, 如果你想以后也不会再上传这个文件或文件夹, 请把这个文件或文件夹添加到。gitignore 文件里, 然后再 push 你的 repo.

2.2.2. 步骤二: 推送我们修改后的 repo

以强制覆盖的方式推送你的 repo, 命令如下:

$ git push origin master --force --all

这个过程其实是重新上传我们的 repo, 比较耗时, 虽然跟删掉重新建一个 repo 有些类似, 但是好处是保留了原有的更新记录, 所以还是有些不同的。如果你实在不在意这些更新记录, 也可以删掉重建, 两者也差不太多, 也许后者还更直观些。

执行结果类似下面:

Counting objects: 4669, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4352/4352), done.
Writing objects: 100% (4666/4666), 35.16 MiB | 51 KiB/s, done.
Total 4666 (delta 1361), reused 0 (delta 0)
To https://github.com/defunkt/github-gem.git
 + beb839d...81f21f3 master -> master (forced update)

为了能从打了 tag 的版本中也删除你所指定的文件或文件夹, 您可以使用这样的命令来强制推送您的 Git tags:

$ git push origin master --force --tags

2.2.3. 步骤三: 清理和回收空间

虽然上面我们已经删除了文件, 但是我们的 repo 里面仍然保留了这些 objects, 等待垃圾回收 (GC), 所以我们要用命令彻底清除它, 并收回空间。

命令如下:

$ rm -rf .git/refs/original/

$ git reflog expire --expire=now --all

$ git gc --prune=now

Counting objects: 2437, done.
# Delta compression using up to 4 threads.
# Compressing objects: 100% (1378/1378), done.
# Writing objects: 100% (2437/2437), done.
# Total 2437 (delta 1461), reused 1802 (delta 1048)

$ git gc --aggressive --prune=now

Counting objects: 2437, done.
# Delta compression using up to 4 threads.
# Compressing objects: 100% (2426/2426), done.
# Writing objects: 100% (2437/2437), done.
# Total 2437 (delta 1483), reused 0 (delta 0)

现在你再看看你的 .git 目录文件大小是不是变小了。

2.3. git 仓库清理瘦身解决 .git 文件夹过大的问题

推荐方案二 BGF 工具清理: (亲测有效 10 分钟搞定)
必备条件

1. 安装 java 环境(java 安装教程)
2. 下载好 bfg 的 jar 包 (下载链接-官网右上角 download 按钮进行下载);

• 第一步: 克隆你的项目 .git 文件

加 –mirror 是只 clone 你项目的 .git 文件

• 第二步: 把你下载的 bfg 的 jar 包复制到这个项目同目录下

• 第三步: 执行命令查看大文件的目录(500 个文件)

git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -500 | awk '{print$1}')"

• 第四步: 最重要的一步

java -jar bfg-1.14.0.jar --delete-folders {dist} --no-blob-protection frontend_saas.git

一分钟左右 1500 个 dist 目录里的文件会全部清除很快; 比 git filter-branch 两个小时快多了

• 第五步: 执行 GC 压缩

git reflog expire --expire=now --all && git gc --prune=now --aggressive

• 第六步: 推送到远程

git push --mirror

• 第七步: 注意项目开发的的小伙伴要全部重新 clone 项目开发; 注意一定不能在原来 400 多兆都是项目里开发提交, 这样项目的垃圾文件又会恢复, 前功尽弃;

总结: 到这里就大功告成了; 446M 的项目清理之后只有 23.7M 干净很多;

3. Git 入门: 从零开始的版本控制之旅

【摘要】 本文介绍了基于 Git 的版本控制基础知识, 包括初始化仓库、提交变更、分支管理和协作开发等关键概念。通过学习这些操作, 你将能够高效地跟踪代码变化, 保护代码质量, 并与团队成员协作开发。这是一次深入浅出的 Git 入门之旅, 让你轻松掌握版本控制的精髓。

3.1. 配置权限

生成本地密钥(主要为了生成 .ssh 目录):

ssh-keygen -t rsa

创建 authorized_keys 文件:

touch authorized_keys

3.2. Git 版本控制概述

git 是分布式版本管理工具, github 是免费的代码托管平台, 一般公司自己有代码托管平台, 如 gitlab。

git 的作用:

1. 保存文件的所有修改历史记录
2. 可随时查看历史版本记录
3. 可回退到指定历史版本
4. 对比不同版本的文件差异
5. 使用版本号进行区分

git 的意义:

1. 多人协作开发大型项目。
2. 为协作开发而生, 大势所趋。
3. 每个人都从代码库下载代码, 然后修改, 将所有人的代码合并后统一上传到平台。
4. 每个公司都有自己的代码托管平台, github 是免费的、开源的托管平台。

3.3. 仓库

3.3.1. 创建远端仓库

在远端创建裸仓库, 实验环境就是虚拟机的 Ubuntu 中创建。

mkdir mathlib
cd mathlib
git init --bare

3.3.2. 本地仓库

拉取远端仓库到本地, 格式如下:

git clone ssh://username@ipaddress:path name
# 例如: git clone ssh://FLY@192.168.1.1:/home/wokspace/mathlib myMathlib

如果不指定文件夹名称, 则将会创建一个和远端仓库同名的文件夹。拉取的文件夹名称可以随意修改, 里面的 .git 目录是本地仓库

3.4. 相关配置

3.4.1. 配置 git 用户名和邮箱

#局部配置
git config user.name name
git config user.email email@email.com

#全局配置
git config --global user.name name
git config --global user.email email@email.com

• 局部配置 只会在当前仓库目录有效, 查看配置信息使用: git config --local -l。配置信息保存在当前仓库的 .git/config。
• 全局配置 可以对所有仓库目录有效, 查看配置信息使用: git cofig -l。配置信息保持在系统盘的用户目录里的 .git/config。

3.4.2. 设置免密访问远端仓库

使用 ssh 协议, 需要生成公钥和私钥; 公钥放在远端服务器, 私钥用于登录验证。使用如下命令生成公私钥:

ssh-keygen -t rsa

产生的文件位于系统盘的用户目录里的 .ssh 文件夹, id_rsa.pub 就是公钥文件, id_rsa 就是私钥文件。将 id_rsa.pub 里的内容复制到远端服务器的 .ssh 目录下的 authorized_keys 文件里即可免密访问远端仓库。

3.5. git 命令基础

3.5.1. 查看状态

git status

untracked files… 表示文件还没被管理

3.5.2. 添加到暂存区 –index

SVN 是没有暂存区的, git 可以把多次修改放在暂存区。

# 格式: 
git add filename
# 示例: 
# 当前的所有修改添加到暂存区
git add .
# 指定文件添加到暂存区
git add newfile.c api.h

3.5.3. 提交到本地仓库 –repository

一般格式:

git commit file -m "message"

示例: 将当前暂存区文件全部提交的本地仓库管理。

git commit . -m "feat:new file"

• . 表示当前目录所有文件, 也可以指定文件
• -m 跟着字符串表示提交描述

3.5.4. 推送到远端仓库 –remote

git push origin master	

• origin 是服务器地址的别名
• master 是分支

3.5.5. 拉取远端仓库到工作目录 –workspace

git pull 

3.5.6. 查看提交日志

# 查看最近记录
git log

#查看所有历史
git reflog  

3.5.7. head 符号引用

在 HEAD 后面加 ^ 或者 ~ 就是以 HEAD 为基准, 来表示之前的版本, 因为 HEAD 被认为是当前分支的最新版本, 那么 HEAD~ 和 HEAD^ 都是指次新版本, 也就是当前版本的上一个版本, HEAD~~ 和 HEAD^^ 都是指次次新版本, 也就是倒数第三个版本, 以此类推。也可以后面跟数字指定后退多少个版本。

3.6. git 逆向操作命令

3.6.1. 暂存区到工作区 index–>workspace

git restore -S filename

撤消工作区的修改返回到最近一次 add(暂存区)的版本或者最近一次 commit 的版本

3.6.2. 本地仓库到暂存区 repository–>index

git restore --soft version

示例: 回退到上一个版本。

git restore --soft head^

head^ 表示上一次的提交。

3.6.3. 本地仓库到工作区 repository --> workspace

git restore --mixed version

示例: 回退到上一个版本。

git restore --mixed head^

head^ 表示上一次的提交。

3.6.4. 本地仓库中删除提交 repository --> NULL

git restore --hard version

# 删除上一个版本
git restore --hard head^

head^ 表示上一次的提交。

3.6.5. restore 不带参数默认是 –mixed

git restore vesrion

等同于

git restore --mixed version

3.6.6. 工作区撤销修改 workspace–>NULL

# 放弃工作区所有修改
git checkout .

# 放弃指定文件修改
git checkout --file

# 放弃暂存区和工作区的所有修改
git checkout -f .

类似于重置, 清除修改标志, 撤销已有文件修改的地方, 但不会删除新增的文件(需要手动去删除)。

3.7. git 本地仓库整理

3.7.1. 整理上次提交

git commit –-amend

把当前暂存区里的内容合并到上一次 commit 里, 而且还可以修改上一次提交的 message 信息

3.7.2. 修改任意的提交

# 修改 hash1 之后的提交信息(不包含 hash1)
git rebase -i hash1

# 修改 hash1 到 hash2 的提交信息(不包含 hash1)
git rebase -i hash1 hash2

这是一种左开右闭的区间, hash1 hash2 分别表示版本号, 如果后面不跟版本号, 那么默认是最近的两次, 此时进入 vi 编辑:

输入相应参数, 比如输入 p 和 e
然后编辑要修改的文件
再通过 add 添加到暂存区
再通过 git commit --amend 整理进去
最后 git rebase --continue 完成整理

如果在修改前所有的 commit 都已经 push 到远程仓库的话, 需要使用:

git push --force

强制推送到远程仓库。

注意: 一定是个人分支整理, 否则可能会修改别人的依赖引起其他人的冲突, 因为每次提交的 hash 值都是不同的。

3.8. git 分支操作

分支的作用是使分支独立变化, 互不依赖。

3.8.1. 查看分支

# 列出本地仓库分支
git branch
#列出本地和远端的分支
git branch -a

3.8.2. 创建分支

# 创建分支
git branch develop
# 创建并切换分支
git checkout -b develop

develop 是分支名称。

3.8.3. 切换分支

	git checkout name
	git switch name

name 表示分支的名称。

3.8.4. 合并分支

步骤:

# 切到 master
git pull
# 解决冲突(解决 master 的冲突, 保证代码最新)
git add  .
git merge --continue //(git update-ref -d MERGE_HEAD)
git commit . -m "message"
git merge develop
# 解决冲突(解决两个分支的冲突, 实现合并)
git add  .
git merge --continue //(git update-ref -d MERGE_HEAD)
git commit . -m "message"
git push origin master

3.8.5. 删除分支

# 删除本地分支
git branch -d develop

# 删除远端分支
git push origin -d develop

develop 表示分支的名称。

3.9. 总结

• 版本控制的重要性: 版本控制是开发过程中必不可少的工具, 它可以帮助我们追踪文件的变化, 协作开发, 并保护代码免受意外错误的影响。
• Git 基础概念: 我们了解了 Git 的三个核心区域, 即工作目录、暂存区和仓库。每个区域都有特定的作用, 帮助我们管理代码的变化。
• 初始化仓库: 通过使用 git init 命令, 我们可以将一个目录初始化为 Git 仓库, 开始进行版本控制。
• 提交与记录变更: 使用 git add 命令将文件添加到暂存区, 然后使用 git commit 命令将暂存区的变更提交到仓库, 并附上一条有意义的提交消息。
• 分支管理: Git 的分支功能让我们能够轻松创建、切换和合并分支。这样可以在开发过程中方便地实验新功能, 同时不影响主线代码。
• 远程仓库与协作: 通过使用远程仓库, 我们可以与团队成员协作开发。常见的操作包括克隆远程仓库、拉取最新代码、推送自己的变更等。
• 撤销与回退: Git 提供了多种方式来撤销或回退操作, 例如使用 git reset 和 git revert 命令。这些命令能够帮助我们修复错误或不必要的提交。