Git学习 —— 裸仓库

原创 已于 2023-03-21 20:12:11 修改 · 2.3k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#git #github

于 2023-03-21 20:11:37 首次发布
裸仓库是只包含.git文件夹的Git仓库，没有工作目录，常用于Git服务器，支持push和fetch操作。它占用空间小，传输速度快，适合代码库的共享和版本管理。创建裸仓库可使用gitinit--bare命令。

什么是裸仓库

可以理解为轻量级的仓库，只包含.git文件夹的仓库。

git分为三个工作区：工作区、暂存区域、Git 仓库，裸仓库实质上就是没有工作目录的Git仓库。它只包含Git版本库中的对象，没有其他的文件或目录。它提供了一种轻量级的方式来共享代码库，因为它占用的空间更小，传输速度更快。

裸仓库和正常仓库的区别

内容不同

裸仓库只有.git文件夹，并没有工作区

clone 方式不同

正常仓库

git clone xxx.git

裸仓库

git clone --bare xxx.git

文件名不同

clone好的裸仓库文件夹以.git结尾。

操作限制

在裸仓库中，只能进行push和fetch操作，不能进行直接的commit或merge操作。这是因为裸仓库没有工作目录，无法进行文件编辑和合并。通常情况下，裸仓库是用来实现 Git服务器的。开发者可以使用它来共享代码库，管理代码版本，保持团队协作等。

附

使用git init --bare <repo>可以创建一个裸仓库

Git裸仓库和非裸仓库
wwwwxhh的专栏
05-27 9112
Git裸仓库创建 使用命令行：git init –bare 使用TortoiseGit：右键菜单git creat repo here，选择Make it Bare   裸仓库可以直接作为服务器仓库供各开发者push、pull数据，实现数据共享和同步，不保存文件，只保存历史提交的版本信息   非裸仓库创建：git init使用TortoiseGit：右键菜单git creat repo h
裸仓库 + Git Bash 搭建 本地 Git 服务端与客户端
积累点滴，保持自我
07-04 715
在Windows上搭建简易Git服务器的方法：1️⃣安装Git时勾选GitBash和OpenSSH；2️⃣创建裸仓库（git init --bare）；3️⃣客户端通过本地路径或SSH克隆仓库；4️⃣局域网访问需开启OpenSSH服务并配置公钥。适用于个人开发或小团队协作，支持本地和SSH两种访问方式。主要命令包括git clone、git push等基本操作，实现轻量级代码版本管理。
Git使用教程之本地仓库的基本操作
likuoelie的博客
09-21 1069
本文是Git本地仓库基本操作教程，适合初学者快速掌握核心功能。教程基于Git 2.46.x版本，涵盖从安装配置到分支管理的完整工作流，包括仓库初始化、文件提交、历史查看、撤销修改等关键操作。提供了命令行示例和常见问题解决方案，并强调最佳实践如清晰提交信息、频繁提交和使用分支。教程还包含进阶提示和图形化查看等实用技巧，帮助开发者建立良好的版本控制习惯。
git本地裸仓库的“激活”：在同一台 Linux 服务器上创建工作区
十年运维开发经验的王义杰在此分享自己的知识和经验
06-23 1202
在 Linux 服务器上，连接到一个本地的 Git 裸仓库并创建标准工作区非常简单，只需要使用 git clone <bare_repo_path> <working_copy_name> 命令即可。
搭建Git本地服务器及其使用
大鹏的专栏
07-05 9132
GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。搭建Git服务器需要准备一台运行Linux的机器，强烈推荐用Ubuntu或Debian，这样，通过几条简单的apt命令就可以完成安装。假设你已经有sudo权限的用户账号，下面，正式开始安装。
git 裸仓库的使用
qq_35845964的博客
02-23 2543
创建裸仓库 git init --bare 初始化裸仓库，用于做为git服务端共享仓库 裸仓不能被clone，需要创建本地初始化一个真实的项目，再添加裸仓为远程推送地址，然后初始化代码推送到远程 mkdir myapp git init git remote add origin <remote_url> git push origin master 如果不初始化裸仓，直接用一个git init创建的目录作为服务端仓库，推送远程的时候有可能会报 master -> master (bra
Git 本地仓库和裸仓库
weixin_34362875的博客
12-03 587
通常我们会用 git init 命令来将我们所在的目录转换为一个 Git 本地仓库或者初始化一个新的空仓库。 用法 将当前目录转换为一个本地仓库 git init复制代码这个命令执行后会在本地生成一个 .git 的文件夹，用来追踪仓库的所有变更。效果如下： git init 指定某个目录成为本地仓库 git init &lt;repo&gt;复制代码这个命令执行后， 将创建一个名为repo...
精选资源
git仓库————迁移脚本
04-14
Git仓库的迁移是一个重要的任务，尤其对于团队协作和项目管理来说。这涉及到将现有的Git仓库从一个服务提供商（如GitHub、GitLab等）迁移到另一个服务提供商，或者在本地环境和远程服务器之间进行迁移。"gitlab-...
Git学习札记——进阶
02-25
如果我使用gitlog,我得到的提交信息是我仓库的一部分。把你当前在工作区中的修改暂时保存起来。然后工作区恢复到上一次提交时的状态。你可以去进行其他的工作了。gitstashlist显示当前工作区中包含的stash。...
Git教程——查看修改日志 (log & diff)
01-08
【Git教程——查看修改日志 (log & diff)】 在Git这个版本控制系统中，每一次对文件的修改都会被单独保存并记录为一个提交（commit）。这些提交就像建筑楼房时的一块块砖石，它们共同构成了项目的整个历史。通过Git...
git寻根——^和~的区别
03-02
在git操作中，我们可以...类似的，每个git仓库都有一本自己的祖谱，仓库中commitID的繁衍，HEAD指针的迁徙，分支的增加、更新，同样的记录着一个仓库从无到有的点点滴滴。在git中，我们其实可以通过^和~来定位某个具体
git裸仓库到底是怎么样的——实践出真知
风轻云淡
08-02 2388
一文懂，如何通过 Git 服务将 Hexo 部署搭建到云服务器上 文章目录一文懂，如何通过 Git 服务将 Hexo 部署搭建到云服务器上双实库，B 克隆 A主体 A Push 到克隆体 B？主体与克隆体之间，相互 PullA 服务器裸库初始化，B 与主机为克隆主动更新上传文件到裸库？获取工作目录的解决办法最后 前些天，给阿里云服务器部署 Hexo 框架写点 Blog，受一篇博客 在阿里云上搭建 Hexo 博客详细流程 的启发，顺手写下了本篇 Blog。 开篇，让我们看一个代码片段： cd /var/rep
Git服务器(中心仓库(裸仓库))搭建
汤键的博客
05-15 3981
Git服务器(中心仓库(裸仓库))搭建
git: Linux中创建中心仓库（or 裸仓库：bare repository)
chenxy_bwave的专栏
04-17 2954
简单介绍在linux系统中创建一个多人协同作业用的git repository的步骤及一些相关设置。这里仅考虑在同一linux服务器内的用户要访问该git-repo，暂不涉及从外部网络访问该git-repo的设置。首先，假定你有管理员权限，并且假定先创建了一个组grp_git，允许该组中的成员访问该共享git repository。
Git仓库
key_1997的博客
08-03 519
获取git仓库的两种方法 git init git clone git仓库有两种： 裸仓库：不带工作区，通常用在服务器上帮助其他用户些协作，并不存在在裸仓库上直接提交变更的情况 创建方式：git init --bare &lt;repo&gt; 本地仓库：一般仓库 创建方式：git init &lt;repo&gt; 区别 从裸仓库clone下来的本地仓库可以...
辛星浅析git init中的--bare选项，也就是裸仓库
辛星，前进的路上.
05-06 4005
通常如果一个仓库作为远程仓库使用的时候，我们初始化的时候通常是git  init  --bare，首先解释一下这个bare，它翻译成汉语即"裸的",他之会生成一类文件，用于记录版本库历史记录的.git目录下面的文件，而不会包含实际项目源文件的拷贝，因此该版本库不能称为工作目录(working  tree)。   当不使用--bare选项时，就会生成.git目录以及其下的版本历史记录文件，这些版本
了解git裸仓库并利用post-receive自动化部署
AlbertS Home of Technology
06-12 3055
【裸仓库】指的是使用 命令得到的仓库，是对这种操作结果的一种直译，这个词对于刚接触 git 软件的小伙伴来说可能是第一次听说，而我也是最近实际操作了几次才渐渐理解，下面解释一下什么是裸仓库，以及为什么要使用它，有理解不对的地方还请大家指正.............
所以较好的步骤是 git add ——> git commit ——> git pull --rebase ——> git push ？
最新发布
09-24
<think> 嗯，用户想确认git操作流程是否合理。从对话历史看，用户关注的是"git add → commit → pull --rebase → push"这个序列的可靠性，还引用了三份关于Git操作的站内资料。 用户可能是中级开发者，正在优化团队协作流程。ta特意提到--rebase选项，说明在意提交历史的整洁性。不过引用材料里多次警告rebase的风险，特别是已推送的提交——这需要重点提醒用户。 核心问题其实是"何时使用rebase"。引用[3]明确说追求线性历史时更适合用rebase，但分支复杂时不推荐。用户当前流程在commit后立即rebase，确实能保持线性，但要注意两个坑：1) 如果commit已经push过，rebase会重写历史；2) 多人协作时可能频繁冲突。 用户没提到功能分支的生命周期。如果ta在个人分支作业，这个流程很完美；但如果分支长期存在，或许在开发早期就用rebase更好——每次push前都rebase反而增加冲突概率。 技术上需要强调细节：pull --rebase本质是fetch+rebase，引用[2][3]都提到它会产生线性历史。但用户流程里commit后马上pull --rebase，相当于把本地新提交"嫁接"到远程更新之后，这正是最标准的rebase用法——只要新提交还没push就安全。 用户可能忽略了备份步骤。引用[1]特别提醒"重大历史重写前创建分支备份"，这个流程虽然不算重写历史，但rebase出错时备份当前分支成本很低，值得补充。 最后想到两个隐藏点：1) 用户用rebase但没提交互模式(-i)，其实可以顺便教ta用squash优化提交；2) 流程最后没提冲突处理，而引用里多次警告rebase可能多次冲突，需要明确说明解决方案。 </think> 根据Git工作流最佳实践和引用内容分析，您提出的 **`git add → git commit → git pull --rebase → git push`** 确实是较为推荐的操作流程，但需结合具体场景谨慎使用。以下是详细解析： --- ### ✅ **流程合理性分析** 1. **`git add`** 将工作区修改加入暂存区，准备提交。 2. **`git commit`** 将暂存区内容生成本地提交记录（此时尚未推送到远程仓库）。 3. **`git pull --rebase`** **关键步骤** = `git fetch` + `git rebase origin/分支名` - 优先将远程最新代码拉取到本地（`fetch`） - 将您的**本地新提交“嫁接”到远程更新之后**（`rebase`），形成线性历史（避免分叉） - *引用支持：* > "`git pull --rebase` 用远程仓库代码更新本地仓库的代码，实现线性合并" [^2][^3] 4. **`git push`** 将本地已对齐远程的提交推送到仓库。 --- ### ⚠️ **适用场景与注意事项** 1. **推荐场景** - 个人开发分支（未与他人共享） - 追求提交历史线性整洁（无多余合并提交） - *引用支持：* > "适合追求整洁、线性历史的项目，尤其是个人分支或简单的协作环境" [^3] 2. **风险与限制** - **已推送的提交禁止 rebase** 若执行 `git commit` 后**已推送过提交**，再 `pull --rebase` 会重写历史，需强制推送（`git push --force`），这将破坏他人基于原提交的工作（引用[1][3]明确警告）。 - **冲突处理更复杂** Rebase 可能需多次解决冲突（每个提交都可能冲突），而 merge 只需一次（引用[3]）。 - **团队协作分支慎用** 多人协作的分支建议用 `git pull`（默认 merge 方式），保留完整合并记录。 --- ### 🔧 **冲突解决方案（关键步骤）** 若 `git pull --rebase` 发生冲突： ```bash # 1. 手动解决冲突文件 # 2. 标记冲突已解决 git add [冲突文件] # 3. 继续 rebase 流程 git rebase --continue # 若需放弃 rebase： git rebase --abort ``` --- ### ✅ **流程优化建议** ```mermaid graph LR A[本地修改] --> B[git add] B --> C[git commit] C --> D{是否已推送过？} D -- 否 --> E[git pull --rebase] D -- 是 --> F[git pull 默认merge] E --> G[解决冲突 git add/rebase --continue] G --> H[git push] F --> H ``` > 📌 **总结建议**： > - **个人分支/未推送**：[优先推荐] `add → commit → pull --rebase → push` > - **多人协作/已推送**：改用 `add → commit → pull (merge) → push` > - **务必操作前备份**：`git checkout -b backup_branch` [^1] --- ### ❓ **相关问题** 1. 如何避免 `git pull --rebase` 导致的历史重写风险？ 2. 多人协作时如何平衡提交历史的整洁性与安全性？ 3. 除了 `rebase`，还有哪些方法优化 Git 提交历史？ > 参考资料： > [^1]: Git squash 合并与 reset 操作指南 > [^2]: `git pull` 与 `git pull --rebase` 工作机制 > [^3]: Rebase 与 Merge 的适用场景对比
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

宇宙超级无敌程序媛

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值