告别Git混乱!Git & GitHub高效协作秘籍:解锁核心命令 × 高效分支管理 × 实战指南
引言
在软件开发和协作中,高效、可靠的版本控制至关重要。Git作为当今最流行的分布式版本控制系统,已成为开发者不可或缺的工具。本指南旨在系统性地介绍Git的核心知识与实践技能。内容涵盖Git的基础概念、安装配置以及命令行下的核心操作。我们将深入探讨项目初始化、提交管理、版本追踪与回滚等基础操作,并重点阐述分支创建与合并这一高效协作的核心策略(强烈推荐)。最后,将指导您如何利用GitHub远程仓库进行代码托管、分支管理以及单/多分支协作流程。通过学习本指南,您将掌握从本地代码管理到远程协作的完整Git工作流,为高效开发奠定坚实基础。
最后,如果大家喜欢我的创作风格,请大家多多关注up主,你们的支持就是我创作最大的动力!如果各位观众老爷觉得我哪些地方需要改进,请一定在评论区告诉我,马上改!在此感谢大家了。
各位观众老爷,本文通俗易懂,快速熟悉git,收藏本文,关注up不迷路,后续将持续分享git纯干货(请观众老爷放心,绝对又干又通俗易懂)。请多多关注、收藏、评论,评论区等你~~~
文章目录
一、Git 概述与安装方式
1.1 Git 概述与使用说明
Git 是当今最流行、最强大的分布式版本控制系统 (DVCS)。它由 Linus Torvalds (Linux 内核创始人) 于 2005 年开发,初衷是为了高效管理庞大的 Linux 内核开发。Git 彻底改变了软件开发中的代码管理方式,其核心思想、工作流程和强大功能使其成为个人开发者和大型团队的必备工具。Git很多的操作指令和Linux基本一致,对Linux环境使用者非常友好!
1. 什么是版本控制系统 (VCS)?
- 简单说,就是一个**“时光机器”** 和 “协作平台”。
- 它记录文件(通常是源代码,但也可是任何文本文件)随时间的变化(版本)。
- 允许你回溯到任意历史版本。
- 支持多人同时修改文件并安全地合并更改。
- 防止代码丢失,方便追踪谁在何时修改了什么以及为什么修改。
2. 分布式 vs 集中式 (如 SVN):
- 集中式 (CVCS): 有一个中央服务器存储所有文件的历史版本。开发者从服务器获取最新版本(
checkout),修改后提交 (commit) 回服务器。工作依赖于中央服务器。 - 分布式 (DVCS - Git):
- 没有绝对的中央服务器概念 (但通常约定一个共享仓库)。 每个开发者都拥有完整的仓库克隆 (Clone),包括所有代码和完整的历史记录。
- 工作不依赖网络: 大部分操作(查看历史、提交更改、创建分支)都在本地完成,速度极快。
- 强大的分支和合并能力: 鼓励频繁创建分支进行特性开发或修复 Bug。
- 更灵活的工作流: 支持多种协作模型(集中式工作流、功能分支工作流、Gitflow、Forking 工作流等)。
- 更高的容错性: 每个人的本地仓库都是备份。即使共享服务器故障,也能从任意开发者的本地仓库恢复。
3. Git 的核心思想:
- 快照 (Snapshot),而非差异 (Delta): 每次提交 (
commit),Git 会为所有被跟踪文件创建一个快照(就像拍了一张项目当前状态的照片),并存储指向该快照的引用。如果文件未修改,Git 只存储一个指向之前相同文件的链接。这使切换分支/版本非常高效。 - 本地操作优先: 提交、分支创建、历史查看等绝大多数操作都在本地完成,无需网络连接。
- 数据完整性: Git 中所有数据在存储前都计算校验和(SHA-1 哈希值)。这意味着不可能在 Git 不知情的情况下更改任何文件或目录内容。这构建了 Git 的核心哲学:一旦提交,数据即不可变。
- 三棵树 / 三个区域: 理解 Git 工作流程的关键:
- 工作目录 (Working Directory / Workspace): 你在电脑上实际看到和编辑的文件目录。这是你的沙盒。
- 暂存区 (Staging Area / Index): 一个中间区域,像一个准备区。你使用
git add命令将工作目录中已修改或新建文件的当前版本放入暂存区。它定义了下次提交将包含哪些更改。 - Git 仓库 (Repository / .git directory): 存储项目元数据和对象数据库的核心。当你执行
git commit时,暂存区的内容会作为一个新的快照永久存储到仓库中。仓库还包含所有分支、标签指针和提交历史。
4. Git 的核心对象:
- Blob (Binary Large Object): 存储文件内容(不包括文件名、权限等元数据)。
- Tree (树): 像一个目录,存储一组 blob(文件)和 tree(子目录)以及它们的名称、权限等元数据。代表某个时刻的目录结构。
- Commit (提交): 代表项目历史中的一个点。包含:
- 指向一个 tree 对象的指针(该提交时刻的项目快照根目录)。
- 指向父提交的指针(通常是前一个提交,形成链式历史)。
- 作者和提交者的信息(姓名、邮箱、时间戳)。
- 提交信息(描述本次修改的原因)。
- Tag (标签): 给某个特定的提交(通常是重要版本如
v1.0) 起一个容易记住的名字。 - Branch (分支): 本质上是一个轻量级的、可移动的指针,指向某个提交。默认分支通常是
main或master。创建新分支只是创建一个新指针。在分支上提交时,该指针自动向前移动。
1.2 Git 基本使用说明 (命令行核心命令)
以下是在日常开发中最常用的 Git 命令和工作流程:
1. 初始化和克隆 (Starting Out)
2. 查看状态和历史 (Knowing Where You Are)
3. 跟踪更改和提交 (Making Changes)
4. 分支管理 (Working with Branches)
5. 远程协作 (Working with Remotes)
6. 处理冲突 (Resolving Conflicts)
7. 撤销操作 (Undoing Things - 谨慎使用!)
1.3 Git 安装方式
Git: Git官网
注意: 不要安装在C盘,教程较多,请自行安装,这里就不再赘述!几分钟即可安装成功。
二、Git 常见操作方式(初高阶)
在开始下面教程之前,请先提前安装pycharm,并在D或者E盘创建一个文件夹,这里以
E:\text为例。
2.1 项目初始化、管理与提交
1. 初始化
- 选择
E:\text文件夹,右击,全部展开,点击Open Git bash here; - 输入初始化命令:
git init - 生成带有
.git文件夹(该文件为隐藏文件,需要调整显示文件才能看见),之后所有的版本都会放到.git文件夹中; - 终端处将弹出带有(master)语句,初始化成功!

2. 管理文件
-
在
text文件夹下创建git_text.py文件(创建文本,修改扩展名即可); -
产看当前文件夹状态,应出现标红文件:
git statusgit status状态说明 红色 修改、创建、删除都是显示红色 绿色 git add添加之后变成绿色白色 git commit提交之后变成白色
-
添加管理文件,将其添加至仓库,如果后面再修改,应重新再进行添加:
git add <file name> # 语法 git add file1 file2 ... # 多个文件 git add . # 所有文件
3. 提交仓库
-
将文件提交至仓库,并对本次提交进行说明(禁止废话,要有实际意义),使用双引号:
git commit -m <message>
-
有些情况会提示你输入用户和邮箱信息,方便溯源,第一次配置后就不需要再进行配置,除非更换用户:
git config --global user.email "you@example.com" git config --global user.name "Your Name" -
查看提交历史
git log
注释: git add 命令用于将工作目录中已修改或新建的文件添加到暂存区(Staging Area),而 git commit 命令则是将暂存区中的所有变更作为一个整体提交到本地仓库(Repository)。每次成功提交(commit)后,Git 会为该次提交生成一个唯一的版本标识符(即提交哈希值,如 a1b2c3d)。后续只需获取目标版本的标识符,即可随时将仓库状态回退(checkout/reset)或查看(log/diff) 到该特定版本。
2.2 版本回滚与查看所有提交记录
1. 版本回滚
- 顾名思义,存在多个版本时(多次commit),而此时是处于最新的版本,如果要返回旧版本这就叫回滚。
git log git reset --hard 版本号(哈希值) # commit 后面很长的那一段代码就是 - 进入不同版本时,
git_text.py文件内容也会与之对应进行变化;
2. 查看所有提交记录
- 当进入旧版本时,使用
git log只能看到当前版本和在此之前的版本,后面的版本不显示,并不是被删除,使用git reflog则可以查看所有提交记录,包括回滚操作:git reflog- 它记录了本地仓库中分支顶端(HEAD)和引用(如分支名、标签名)的所有变更历史。
HEAD指针的每一次移动;所有本地分支指针(如main,feature-branch)的每一次移动;git stash操作;git pull,git merge,git rebase,git commit,git checkout,git reset等几乎所有改变引用的操作; 关键点:只记录本地操作!不记录远程仓库的变化。 - 特点与限制:
- 本地性:
reflog信息只存储在你的本地.git目录中,不会被推送到远程仓库。克隆一个新仓库时,不会包含原仓库的reflog。 - 时效性: Git 会定期清理旧的
reflog条目(默认大约 90 天)。所以它不是一个永久的备份方案,但对于近期操作失误的恢复极其有效。 - 操作粒度: 它记录的是引用(HEAD、分支名)的变更,而不是文件内容的变更。它告诉你 HEAD 从提交 A 移动到了提交 B,但不告诉你 A 和 B 之间文件具体怎么变的(那是
git log和git diff的工作)。
- 本地性:
- 查看特定引用的 reflog (如分支名):
git reflog show <branch-name> # 例如 git reflog show main
- 它记录了本地仓库中分支顶端(HEAD)和引用(如分支名、标签名)的所有变更历史。
- 重写提交历史(变基):
git rebase(Re-base) 是一个改变提交历史的强大工具。它的核心思想是将一个分支上的提交“重新播放”到另一个分支(通常是更上游的基础分支)的最新提交之上。后面再对这部分内容进行重点讲解。
2.3 暂存区存储代码(不推荐使用!)
1. 在开发过程中,发现之前代码存在bug
这种情况主要分为两种:是否在同一文件。如果是同一文件,则建议直接手动修改即可,如果使用 git stash ,则会产生冲突。
如果是存在于不同文件中,则可尝试使用 git stash 这种方法。
2. 使用暂存区存储代码
- 查看文件状态,此时“写一半的文件应该为红色”:
git status - 储存未提交的文件(未使用
add和commit)git stash - 在此查看文件状态时,则已经没有标红:
- 修改完成后,将暂存的代码拿回来:
git stash pop
3. 其他 git stash 操作
| 指令 | 操作说明 |
|---|---|
git stash list |
查看“某个地方”存储的所有记录(暂存的记录) |
git stash clear |
清空“某个地方”(清空所有的暂存) |
git stash pop |
将第一个记录从“某个地方”重新拿到工作区(可能有冲突)(就是上面stast@{0},取数字最大的那一个,数字就是暂存的编号) |
git stash apply |
编号,将指定编号的记录从“某个地方”重新拿到工作区(可能有冲突) |
git stash drop |
编号,删除指定编号的记录 |
注释: 实际生产中,并不会使用这种方式,更多采用下面的分支方式进行,不仅便于修改bug,也便于进行合理地分工协同。
2.4 创建分支(branch)与合并(merge)(强烈推荐!)
1. 创建与切换分支
- 创建分支,并切换到新建分支环境:
git branch <分支名> # 创建分支 git checkout <分支名> # 进入分支 # 实例 git branch dev git checkout dev - 常规操作
touch a.log vi a.log git add . git commit -m "bug replacement"
2. 合并与删除废弃分支
- 将 dev 分支合并到 master 中:
git merge <分支名> - 删除废弃分支(已合并):
git branch -d branch_name
三、Github远程仓库使用
3.1 注册Github账号
Github官网: Github,注册完成后,则为如下界面:

3.2 分支管理策略
在Git中,分支管理策略是协作开发的核心。主流的分支管理策略包括Trunk-Based Development、Feature Branching和Git Flow等。本文将重点介绍Feature Branching策略,它是一种简单且常用的策略。
Feature Branching策略的核心思想是从主分支(master)上拉取feature分支来开发新功能或特性。这样,开发者可以在feature分支上独立开发,而不影响主分支的稳定性。开发完成后,通过提交pull request将feature分支合并回master分支。这个过程中,其他团队成员可以对即将合并的代码进行审核,确保代码的安全性和可靠性。
单分支与多分支协作
Git协作可以在单分支或多分支上进行。在单分支协作中,所有开发者在同一分支上工作,这可能会导致频繁的合并冲突。而在多分支协作中,每个开发者在自己的分支上独立工作,只在最后合并分支时解决冲突,这样可以减少冲突的发生。
(一)单分支协作流程
- 准备工作:开发者需要克隆远程仓库,并将其他成员添加到项目中。
- 创建分支:可以直接在远程仓库创建分支,或在本地创建后推送到远程仓库。
- 在分支上开发:开发者在本地feature分支上进行开发,并与远程分支建立连接。
- 分支合并:在合并分支前,应先将master分支合并到feature分支上,解决冲突后再合并回master分支。
- 清理:开发完成后,应删除不再使用的feature分支,保持仓库整洁。
(二)多分支协作流程
- 创建分支:每个开发者在本地创建自己的feature分支,并推送到远程仓库。
- 在分支上开发:开发者在各自的分支上独立开发,并提交到远程分支。
- Pull Request:通过提交pull request请求将feature分支合并到master分支。如果遇到冲突,应先将master分支合并到feature分支上解决冲突,然后再合并回master分支。
- 清理:合并完成后,删除不再需要的远程和本地feature分支。
- 解决合并冲突
注释: 合并冲突是协作开发中常见的问题。解决合并冲突的关键是及时更新本地分支,保持与远程仓库同步。在遇到冲突时,可以手动解决冲突,或使用工具如vscode来辅助解决。解决冲突后,再次提交代码以完成合并。
3.3 单/多分支具体操作流程
1. 单分支操作流程
-
创建仓库

-
添加合作者

2. 单/多分支推送操作
- 添加储存仓库地址
git remote add <地址名(随意起)> <Github代码地址HTTPS> - 推送至远程仓库
这步需要登陆Github,会有弹窗。git push <地址名> <要推送的分支>
3. 克隆与拉取
- 克隆,从远程仓库中将代码克隆下来
git clone <HTTPS地址> - 拉取分支代码
git branch <分支名> git checkout <分支名> git pull origin <Github中你希望拉取的分支>
能够看到这里的观众老爷,无疑是对up的最大肯定和支持,在此恳求各位观众老爷能够多多点赞、收藏和关注。在这个合集中,未来将持续给大家分享关于git的多种常见开发实用操作。未来也将继续分享各种实用干货。感谢大家支持!
更多推荐




所有评论(0)