git教程-仓库概述、基操

最新推荐文章于 2025-11-27 15:44:49 发布

原创最新推荐文章于 2025-11-27 15:44:49 发布 · 156 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#git

git 专栏收录该内容

2 篇文章

订阅专栏

本文详细介绍了Git仓库的概念，包括仓库的建立、工作区、暂存区和分支的作用。同时，提供了基本的Git操作指南，如查看仓库状态、暂存文件和提交文件等，帮助初学者快速掌握Git的基本使用。

5. 仓库

对应的就是一个目录，这个目录中的所有文件被git管理起来。

以后会将一个项目的根目录，作为仓库。

仓库中的每个文件的改动都由git跟踪。

5.1 新建仓库

选择一个目录，执行指令：git init

新建仓库	仓库目录

5.2 工作区

执行git init的目录即为工作区，如上例，D:\repo1目录即为工作区【不包含.git目录】

所有文件，都首先在工作区新建，然后可以存入仓库(版本库)，进行版本控制。

5.3 暂存区

暂存区也在 .git 目录内，工作区的文件进入仓库时，要先进入暂存区。

5.4 分支

版本控制，简单说，就是记录文件的诸多版本，分支就是这些版本的最终记录位置。

6. 基本操作

6.1 查看仓库状态

执行 git status 可以看到工作区中文件的状态

未记录过的文件，是`未跟踪`状态

6.2 暂存文件

执行 git add . 将工作区中的文件全部存入暂存区

将工作区中的文件存入暂存区

6.3 提交文件

执行 git commit -m "这里写提交的描述信息" 作用是将暂存区的文件存入分支，形成一个版本

提交文件，形成一个版本

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

java_zhj9

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

Git 教程-第一篇：Git 入门-基础概念与安装配置

无

06-05

127

Git入门指南：基础概念与安装配置版本控制系统（VCS）是软件开发必备工具，Git作为分布式VCS的典型代表，解决了代码历史追溯、多人协作和分支管理等核心问题。与传统集中式VCS（如SVN）相比，Git具有本地完整仓库、离线操作和更高容错性等优势。安装Git时，Windows用户可直接下载安装包，macOS推荐使用Homebrew，Linux通过包管理器即可完成。初始配置需设置全局用户信息（姓名/邮箱），并建议配置SSH密钥实现远程仓库的免密安全连接。这些基础工作为后续版本控制操作奠定必要基础。

保姆级Git教程1-Git概述

2301_79272029的博客

04-29

354

Git的使用场景。备份老六在开发的过程中，电脑突然蓝屏，硬盘光荣牺牲，几个月的努力付之东流代码还原项目需要一个复杂的功能，老六反复修改尝试，摸索了一个星期终于有眉目了，可是他这个星期做的修改都不对，应该从一个星期前的代码开始改，这时他多么希望能回到从前。协同开发小刚和小强先后以文件服务器上下载了同一个文件:Analysis,java:小刚在Analysis.java文件中的第30行声明了一个方法，叫count()，先保存到了文件服务器上;

参与评论您还未登录，请先登录后发表或查看评论

第一节：Git概述、基本概述和初步使用（关键词：Git安装、Git配置、git config --global、git log、工作区、暂存区、版本库、HEAD指针）

快乐江湖的博客

03-29

349

Git：Git 是一个开源的分布式版本控制系统（软件），用于敏捷高效地处理任何或小或大的项目。由Linus Torvalds于2005年创建的。Git旨在帮助开发人员更好地管理代码的变更，从而使多人协作更加高效和简单。使用Git，开发人员可以在本地保存代码的版本历史记录，并与其他开发人员共享和协作分布式代码库不仅存在于中央服务器上，而且每个开发人员都可以将代码库完整地复制到本地，并在本地进行开发和版本控制的能力。

Git -- git push -u origin master

热门推荐

小微分享驿站

03-24

1万+

Linux下Git命令行使用中使用 git push -u origin master失败的解决办法

保姆级Git教程5-Git远程仓库及其相关操作

2301_79272029的博客

05-01

1444

创建远程仓库、配置SSH公钥、操作远程仓库、关联远程仓库、查看远程仓库、本地仓库推送到远程仓库***、本地分支与远程分支的关联与关系、从远程仓库克隆clone到本地、从远程仓库中抓取和拉取、解决克隆仓库或本地仓库无法推送的问题、解决远程抓取后合并冲突

git 历史记录想隐藏？git filter-branch 指令，改写提交历史（慎用）

2503_92849134的博客

08-11

747

接着详细介绍指令的基本概念、适用场景，分步讲解具体操作方法，包括修改提交者信息、删除文件历史等，还列举常见问题及解决办法，最后总结使用要点，提醒用户谨慎操作，避免造成不可挽回的损失，为有需要改写 Git 历史记录的用户提供全面且实用的参考。其中，--index-filter用于修改索引，git rm --cached --ignore-unmatch 文件名表示从索引中删除指定的文件。需要注意的是，强制推送会覆盖远程仓库的历史记录，因此在执行该操作前，一定要确保团队成员都知晓，并且已经备份了重要的代码。

用 git reset --hard 回退代码，把 3 天工作量删没了

2503_92604243的博客

08-12

575

执行git fetch origin获取远程最新提交，再用git log origin/main查看远程分支的提交记录，找到包含丢失代码的提交后，通过git cherry-pick <commit-id>将该提交应用到当前分支。git reset --hard的 “硬重置” 特性会强制将当前分支指向指定的提交，同时清空工作区和暂存区的所有未提交修改，并覆盖与目标提交不一致的文件。为避免再次陷入类似困境，需深入理解git reset的三种模式（--soft、--mixed、--hard）及其差异：。

Git---分布式版本控制工具

weixin_73253843的博客

08-03

1969

Git 是一个开源的分布式版本控制系统，最初由Linus Torvalds为了管理Linux内核开发而开发。它具有以下主要特点和功能： 1.分布式版本控制： Git 是一种分布式版本控制系统，意味着每个开发者的本地计算机上都有完整的版本库。这使得开发者可以在没有网络连接的情况下进行工作，并且能够在多个远程仓库之间同步和共享变更。 2.版本管理： Git 能够追踪和管理文件的各种版本变更。每次提交（commit）代表了项目的一个快照，并且可以方便地回溯、比较和恢复历史版本。

git 分支堆成山？用 git branch -d + grep 指令批量清理，清爽多了

2503_92604243的博客

08-11

587

然而，随着项目的推进，仓库中的分支会像滚雪球一样越来越多 —— 完成的功能分支、废弃的测试分支、过时的修复分支等堆积在一起，不仅会让开发者在切换分支时眼花缭乱，增加操作失误的风险，还可能拖慢仓库的响应速度，影响开发效率。仔细查看分支列表，区分出已完成合并的功能分支、过时的测试分支等需要清理的分支，以及 main、develop 等需要保留的核心分支。-v选项表示反向匹配，即排除包含 “main” 或 “develop” 的分支，该命令会列出除核心分支外的其他分支，适合进行大范围清理时保留关键分支。

Git基础-删除文件 rm/git rm 命令详解

northcastle的博客

08-23

1万+

1.文章概述本文介绍git中删除文件的操作；主要涉及命令如下： 1.rm 2.git rm 3.git rm -f 4.git rm --cached 5.git rm -r : 在删除文件夹的时候，使用参数 -r 表示循环删除文件夹中的内容（不做详细介绍）【注意】：以下介绍的内容都是在被删除文件已经纳入版本控制的前提下。 2.rm命令介绍 1.rm 是linux中的删除命令； 2.rm 命令的效果就如同我们在 windows 下直接使用右键删除

Git-2.30.0-64-bit

01-04

Git是世界上最流行的分布式版本控制系统，它允许开发人员追踪和管理代码变更，促进团队协作。"Git-2.30.0-64-bit"是指Git的2.30.0版本，专为64位操作系统设计。这个压缩包可能包含了Git的安装程序（Git-2.30.0-64-...

gitpush-http-ssh-Linux常用命令学习资源

06-21

在Linux环境下使用git push命令时，用户将学会如何创建和切换分支、如何提交更改到本地仓库、如何添加远程仓库并建立连接、以及如何推送更改到远程仓库等操作。这些知识对于任何使用git进行软件开发的人员来说都是...

Git：版本控制工具Git的详细介绍

qq_42279379的博客

11-26

661

Git的本质使用“快照+引用链”串联所有的历史快照：项目中所有文件的完整切片，被修改的文件会被完整记录，没有被修改的文件会复用；通过 “硬链接复用”—— 未修改的文件，新快照不存新数据，只存一个指向旧快照中该文件数据的 “指针”引用链：每次git commit，都会生成一个提交对象，这个提交对象包含三个数据区域（一个父指针、一个快照指针、还有一些元数据）；父指针记录前一个提交的指针，快照指针记录当前提交时刻的快照对象，元数据包含提交时的注释、提交时间、作者信息等；

Git-IDEA 02 GitEE邀请小组成员

欢迎订阅我的“JAVA全栈开发笔记（全）”专栏，价格优惠，仅需19.9元。

11-25

一、打开仓库成员管理二、邀请小组成员三、受邀者确认

Git Fork 开发全流程教程

深耕嵌入式领用多年，致力于分享嵌入式领域技术!

11-27

245

Git Fork 开发全流程教程

DevOps技能提升路径

2509_93946509的博客

11-25

369

概念比较多，Pod、Deployment、Service、Ingress、ConfigMap、Secret这些核心资源对象得理解透。不光是会用ECS、VPC这种基础服务，更要了解它的高可用架构、安全产品（如WAF、安全组）、存储和数据库服务等。在CI/CD流程中集成安全扫描，比如镜像漏洞扫描（Trivy）、代码安全扫描（SonarQube）、依赖项检查等，把安全作为流程的一个必要环节，而不是事后补救。成本优化：能对云上资源的消耗进行分析和优化，帮公司省钱，这是非常重要的能力。这一步是基本功，没得偷懒。

Git在代码中的版本管理

2509_93947330的博客

11-25

272

从单兵作战到百人协作，Git用得好能让你：代码回溯有据、协作冲突可控、发布风险可防。毕竟，我们管理的不只是代码，更是产品演化的生命线。比如我们团队硬性规定：分支永远对应生产环境，分支做集成测试，功能开发一律走分支。遇到冲突别慌，首先用让冲突显示三窗格（本地代码+远程代码+共同祖先）。更骚的操作是：交互式选择哪些改动需要暂存，比如只存某个文件的修改，其余保持工作区状态。最后安利个神器，曾经有同事误删分支差点崩溃，结果用这命令找回了丢失的commit。所以说，只要没执行，Git几乎总能给你后悔药。

项目开发使用 git工作流插件 -- jgitflow开发实践

fluetty--成长中的菜鸟

11-25

317

Chromium 140 编译指南 macOS 篇：获取源代码（四）

最新发布

守城小轩的技术窝棚

11-27

491

经历了三篇的系统配置、Xcode 部署和 depot_tools 安装，我们终于来到了一个关键转折点——获取 Chromium 140 的完整源代码。这一步标志着从"准备阶段"到"实践阶段"的真正跨越。Chromium 的源码库包含了数十年浏览器技术演进的结晶，超过 20 万个源文件和数百万行代码，是现代浏览器工程的一部典范。

git pull 和 git pull --rebase的区别

09-09

<think> 首先，用户的问题是："我想了解git pull和git pull --rebase的区别"，具体询问两者的区别。参考提供的引用内容，我需要整合这些信息给出清晰的解释。关键引用总结： - 引用[1]: git pull 是 git fetch + git merge（默认），生成合并提交；git rebase 将当前分支的提交“重新播放”到目标分支上，创建线性历史。 - 引用[2]: git pull 创建合并提交，可能导致历史分叉；git pull --rebase 保持线性历史。 - 引用[3]: git pull --rebase 适用于追求整洁历史的项目；git pull 适用于保留完整历史；git pull --rebase 可能重写历史，需谨慎。 - 引用[4]: git pull --rebase 就是 git fetch + git rebase。 - 引用[5]: 在rebase过程中，出现冲突时需手动解决，然后执行 git rebase --continue。用户的上一次问题也是关于这个区别，所以我需要确保回答结构清晰，逐步解释。系统级指令： - 所有行内数学表达式用 $...$（但这里可能不涉及数学，所以忽略）。 - 独立公式用 $$...$$（同样不适用）。 - LaTeX语法正确（不适用）。 - 使用中文回答。 - 生成相关问题。 - 引用的段落末尾添加引用标识，例如 [^1]。回答结构： 1. **解释基本区别**：简述 git pull 和 git pull --rebase 的核心概念。 2. **对比细节**：包括工作方式、历史记录、冲突处理、适用场景等。 3. **何时使用**：给出建议。 4. **注意事项**：提到潜在问题，如历史重写。 5. **生成相关问题**：在末尾添加相关问题。引用标识：我需要从提供的引用中自然地添加引用。引用有 [^1] 到 [^5]，所以我应该引用这些来源。大纲回答： 1. **引入**：简要介绍两者的共同点和区别。 - 两者都用于同步代码，但工作方式不同。 2. **核心区别**： - git pull：默认是 git fetch + git merge，创建合并提交。 - git pull --rebase：是 git fetch + git rebase，线性历史。 3. **工作流程对比**： - git pull 会导致历史分叉；git pull --rebase 保持线性。 4. **冲突处理**： - git pull：一次性解决冲突。 - git pull --rebase：每个提交可能单独解决冲突。 5. **适用场景**： - git pull：适合公共分支（如 main），保留完整历史。 - git pull --rebase：适合私有分支或个人分支，追求整洁历史。 6. **注意事项**： - git pull --rebase 可能重写历史，不适合已推送的提交。 7. **总结**：给出建议。 8. **相关问题**：生成一些相关问题。生成相关问题：基于内容，如： - 如何解决在使用 git pull --rebase 时出现的冲突？ - 在团队协作中，推荐使用哪个命令？ - 什么是合并提交（Merge Commit）？ - 如何配置 Git 以默认使用 git pull --rebase？确保中文回答。 </think> ### Git pull 和 Git pull --rebase 的区别在 Git 中，`git pull` 和 `git pull --rebase` 都用于从远程仓库同步代码到本地分支，但它们在合并方式、历史记录处理和适用场景上有显著差异。下面我将逐步解释核心区别，帮助您更好地理解两者。 #### 1. **核心区别概述** - **`git pull`**: 默认行为是 `git fetch`（下载远程更改）加上 `git merge`（合并到本地分支）。这会产生一个**合并提交（Merge Commit）**，导致提交历史出现分叉。例如： ``` $ git checkout main $ git pull origin main ``` 结果：本地分支添加一个新提交（合并点），历史记录可能包含分支和合并点 [^1][^2]。 - **`git pull --rebase`**: 等效于 `git fetch` 加上 `git rebase`（变基）。它将您的本地提交“重新播放”到远程分支的最新提交之上，创建**线性历史记录**。例如： ``` $ git pull --rebase origin main ``` 结果：本地提交被移动到远程分支的顶部，历史记录保持一条直线，避免了额外合并提交 [^3][^4]。 #### 2. **详细对比** 下表总结了关键差异（基于引用内容整合）： | 特性 | `git pull`（默认） | `git pull --rebase` | |----------------------|---------------------------------------------|---------------------------------------------| | **本质** | `git fetch` + `git merge` | `git fetch` + `git rebase` | | **历史记录** | 生成合并提交，可能导致分叉历史 | 线性历史，无额外合并点 | | **冲突处理** | 一次性解决所有冲突（在合并时） | 每个本地提交单独解决冲突（可能需要多次处理）| | **是否重写历史** | 否（保留原始提交） | 是（修改提交的 SHA-1 值） | | **适用场景** | 公共分支（如 `main`）、保留完整历史日志时 | 私有或个人分支、追求整洁线性历史时 | | **示例工作流程** | 直接合并，适合团队协作复杂的环境 | 变基，适合简化历史或个人开发环境 | - **冲突处理细节**: - 在 `git pull` 中，如果本地和远程有冲突，Git 会暂停并要求您一次性解决所有冲突（完成后自动生成合并提交）。 - 在 `git pull --rebase` 中，冲突可能在每个本地提交重放时出现，需手动解决每个冲突，然后运行 `git rebase --continue` 继续 [^5]。这会保留历史线性但过程更繁琐。 #### 3. **何时使用** - **优先使用 `git pull`**: 当工作在公共分支（如 `main` 或 `develop`）时，保留合并历史有助于追踪分支演变，适合多人协作项目 [^1][^2]。 - **优先使用 `git pull --rebase`**: 当工作在私有分支或个人功能分支时，能避免历史污染，保持提交记录整洁。这在代码审查或追求简单历史的环境中很有用 [^3][^4]。 #### 4. **注意事项** - **历史重写风险**: `git pull --rebase` 会修改提交的 SHA-1 值，如果本地提交已推送到远程仓库，使用时需谨慎，否则可能导致历史不一致（推荐只在未推送的提交上使用）[^3]。 - **默认设置**: 可通过 `git config --global pull.rebase true` 将 `git pull --rebase` 设为默认行为，简化操作 [^4]。 - **一般建议**: 在团队项目中，遵循团队约定；个人开发中可选择变基以优化历史。 #### 5. **总结** `git pull` 和 `git pull --rebase` 的核心区别在于合并机制：前者通过合并创建分支历史，后者通过变基维护线性历史。选择取决于您的需求—保留完整历史还是简化记录。掌握两者能提升 Git 工作流效率 [^1][^2][^3]。如果您有具体场景（如冲突解决），我可以提供更详细的步骤！