git学习——远程仓库的使用

最新推荐文章于 2025-12-05 17:57:22 发布
转载 最新推荐文章于 2025-12-05 17:57:22 发布 · 1.5k 阅读 · 0
文章标签：

#服务器

本文详细介绍了如何管理Git远程仓库，包括查看、添加、删除远程仓库，以及如何使用fetch和push命令进行数据的抓取和推送。通过实例演示了如何从远程仓库拉取数据并合并到本地仓库，以及如何将本地仓库的数据推送到远程仓库。

远程仓库的使用

要参与任何一个 Git 项目的协作，必须要了解该如何管理远程仓库。远程仓库是指托管在网络上的项目仓库，可能会有好多个，其中有些你只能读，另外有些可以写。同他人协作开发某个项目时，需要管理这些远程仓库，以便推送或拉取数据，分享各自的工作进展。管理远程仓库的工作，包括添加远程库，移除废弃的远程库，管理各式远程库分支，定义是否跟踪这些分支，等等。本节我们将详细讨论远程库的管理和使用。

查看当前的远程库

要查看当前配置有哪些远程仓库，可以用git remote命令，它会列出每个远程库的简短名字。在克隆完某个项目后，至少可以看到一个名为 origin 的远程库，Git 默认使用这个名字来标识你所克隆的原始仓库：

$ git clone git://github.com/schacon/ticgit.git
Initialized empty Git repository in /private/tmp/ticgit/.git/
remote: Counting objects: 595, done.
remote: Compressing objects: 100% (269/269), done.
remote: Total 595 (delta 255), reused 589 (delta 253)
Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
Resolving deltas: 100% (255/255), done.
$ cd ticgit
$ git remote 
origin

也可以加上-v选项（译注：此为 --verbose 的简写，取首字母），显示对应的克隆地址：

$ git remote -v
origin  git://github.com/schacon/ticgit.git

如果有多个远程仓库，此命令将全部列出。比如在我的 Grit 项目中，可以看到：

$ cd grit
$ git remote -v
bakkdoor  git://github.com/bakkdoor/grit.git
cho45     git://github.com/cho45/grit.git
defunkt   git://github.com/defunkt/grit.git
koke      git://github.com/koke/grit.git
origin    git@github.com:mojombo/grit.git

这样一来，我就可以非常轻松地从这些用户的仓库中，拉取他们的提交到本地。请注意，上面列出的地址只有 origin 用的是 SSH URL 链接，所以也只有这个仓库我能推送数据上去（我们会在第四章解释原因）。

添加远程仓库

要添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用，运行git remote add [shortname] [url]：

$ git remote
origin
$ git remote add pb git://github.com/paulboone/ticgit.git
$ git remote -v
origin  git://github.com/schacon/ticgit.git
pb  git://github.com/paulboone/ticgit.git

现在可以用字串 pb 指代对应的仓库地址了。比如说，要抓取所有 Paul 有的，但本地仓库没有的信息，可以运行 gitfetch pb：

$ git fetch pb
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 44 (delta 24), reused 1 (delta 0)
Unpacking objects: 100% (44/44), done.
From git://github.com/paulboone/ticgit
 * [new branch]      master     -> pb/master
 * [new branch]      ticgit     -> pb/ticgit

现在，Paul 的主干分支（master）已经完全可以在本地访问了，对应的名字是 pb/master，你可以将它合并到自己的某个分支，或者切换到这个分支，看看有些什么有趣的更新。

从远程仓库抓取数据

正如之前所看到的，可以用下面的命令从远程仓库抓取数据到本地：

$ git fetch [remote-name]

此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支，一探究竟。（我们会在第三章详细讨论关于分支的概念和操作。）

如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。所以，git fetchorigin会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch 以来别人提交的更新）。有一点很重要，需要记住，fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。

如果设置了某个分支用于跟踪某个远端仓库的分支（参见下节及第三章的内容），可以使用 git pull 命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用，既快且好。实际上，默认情况下 git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支（假设远程仓库确实有 master 分支）。所以一般我们运行 git pull，目的都是要从原始克隆的远端仓库中抓取数据后，合并到工作目录中当前分支。

推送数据到远程仓库

项目进行到一个阶段，要同别人分享目前的成果，可以将本地仓库中的数据推送到远程仓库。实现这个任务的命令很简单： git push [remote-name] [branch-name]。如果要把本地的 master 分支推送到origin 服务器上（再次说明下，克隆操作会自动使用默认的 master 和 origin 名字），可以运行下面的命令：

$ git push origin master

只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，并到自己的项目中，然后才可以再次推送。有关推送数据到远程仓库的详细内容见第三章。

查看远程仓库信息

我们可以通过命令 git remote show [remote-name]查看某个远程仓库的详细信息，比如要看所克隆的 origin 仓库，可以运行：

$ git remote show origin
* remote origin
  URL: git://github.com/schacon/ticgit.git
  Remote branch merged with 'git pull' while on branch master
    master
  Tracked remote branches
    master
    ticgit

除了对应的克隆地址外，它还给出了许多额外的信息。它友善地告诉你如果是在 master 分支，就可以用 git pull 命令抓取数据合并到本地。另外还列出了所有处于跟踪状态中的远端分支。

实际使用过程中，git remote show 给出的信息可能会像这样：

$ git remote show origin
* remote origin
  URL: git@github.com:defunkt/github.git
  Remote branch merged with 'git pull' while on branch issues
    issues
  Remote branch merged with 'git pull' while on branch master
    master
  New remote branches (next fetch will store in remotes/origin)
    caching
  Stale tracking branches (use 'git remote prune')
    libwalker
    walker2
  Tracked remote branches
    acl
    apiv2
    dashboard2
    issues
    master
    postgres
  Local branch pushed with 'git push'
    master:master

它告诉我们，运行 git push 时缺省推送的分支是什么（译注：最后两行）。它还显示了有哪些远端分支还没有同步到本地（译注：第六行的 caching 分支），哪些已同步到本地的远端分支在远端服务器上已被删除（译注：Staletracking branches 下面的两个分支），以及运行 git pull 时将自动合并哪些分支（译注：前四行中列出的 issues 和master 分支）。

远程仓库的删除和重命名

在新版 Git 中可以用 gitremote rename命令修改某个远程仓库的简短名称，比如想把 pb 改成 paul，可以这么运行：

$ git remote rename pb paul
$ git remote
origin
paul

注意，对远程仓库的重命名，也会使对应的分支名称发生变化，原来的 pb/master 分支现在成了paul/master。

碰到远端仓库服务器迁移，或者原来的克隆镜像不再使用，又或者某个参与者不再贡献代码，那么需要移除对应的远端仓库，可以运行git remote rm命令：

$ git remote rm paul
$ git remote
origin

 

 

你好! Git——远程仓库与本地仓库交互管理
plj521的博客
07-30 1448
前面所说的所有内容（⼯作区，暂存区，版本库等等）， 都是在本地，现在我们学习远程仓库
Git入门——windows环境下git连接github远程仓库
zhen921的博客
02-27 5256
既然使用git了，远程仓库的连接配置是一定要学的，好处也是显而易见的，在我看来远程仓库的好处主要有两点： 一是可以作为本地仓库的一个备份，这样项目会更有保险。 二是有了远程仓库更方便团队的协作开发。 连接远程仓库简单来说四步就够了。 建立本地仓库和远程仓库 本地生成钥匙 把钥匙放到github上 本地连接github 第一步 建立仓库 既然我们要连接远程仓库，那前提是远...
Git入门基础及常用操作
W2279567793的博客
03-18 654
一篇不够还有一篇
TortoiseGit Resolving deltas: 100%问题的解决
至虛極，守靜篤
01-25 7866
近日，一时手疼，升级了TortoiseGit到最新版本（win7 64位）。结果在clone一个新仓库时，出现了怪事，文件下载完毕之后，一直停留在Resolving deltas: 100%....状态，挂起了。本地已经生成目录，就是看不到文件。         于是乎一阵忙活，终于找到原因。旧版本使用PUTTY 0.6.2的SSH通信，而最新版本使用的是0.6.3的。PUTTY/LLINK间的
关于git的submodule
weixin_33786077的博客
06-20 167
http://blog.cnrainbird.com/index.php/2012/05/31/guan_yu_git_de_submodule/ 搞开发的都大都知道章鱼猫吧(github，哈哈~~)。里面有各种智慧的结晶合理利用，事半功倍。可是最近发现里面稍微复杂一些的工程都开始整submodule了。无论是直接zip下载，还是clone的，submodule都是空的，这样的运行肯定会提示缺少...
Git命令汇总二
西瓜の春天的博客
10-10 679
接着上一篇继续罗列Git的命令。 命令的记录顺序主要是按照廖雪峰老师的文章顺序，再次感谢！ 红色字体代表Git命令，蓝色字体为代码块。 15、命令 git remote add origin git@github.com:liuqinghui/repositroy_name.git         将本地仓库添加到GitHub的远程仓库（liuqinghui为GitHub账户名）
11：git 远程操作详解
weixin_30562507的博客
05-06 177
git 远程操作详解 .git文件:版本库区域 refs heads:分支管理 master remotes：主机名管理 demo origin HEAD--ref: refs/remotes/origin/master master--1b2d350606821fd90952038bf0b66fdadf94ae8d tags：标签管理 v1.0 config HEAD--...
git仓库————迁移脚本
04-14
5. **推送代码**：执行`git push -u origin --all`将本地所有分支推送到新创建的远程仓库。如果需要推送标签，使用`git push --tags`。 6. **迁移Webhooks和CI/CD配置**：Webhooks用于触发外部服务的事件，如自动化...
Git入门——远程仓库及分支管理
贰拾肆樵
02-13 2876
前面提到，Git相对于传统的SVN有着很大的优势，其中之一就在于集中式系统中，版本库只能存在于中央服务器上；而在Git中，版本库可以克隆多个，甚至在同一台主机中也可以克隆多个版本库。当然，日常开发过程中，还是会有一台主机充当中央服务器的角色，作为整个项目的整体基准。我们可以自己搭建一个git服务器，也可以直接使用github所提供的免费仓库托管服务。 在本文中我们使用GitHub。在使用之前，需要注册GitHub账号，并且在本地与GitHub上设置SSH，具体操作请参照
《ProGit》——Git使用和原理讲解
11-14
此外，书中还涵盖了与远程仓库交互、协作开发流程以及Git与其他工具的集成等内容，全面覆盖了Git的全貌。 总的来说，《ProGit》是一本全面而实用的Git教程，无论是个人项目还是团队协作，都能从中获益良多。通过...
Linux 下搭建Git 服务器详细步骤
a77687789的博客
06-04 968
参考： https://www.cnblogs.com/dee0912/p/5815267.html#_label0 https://blog.youkuaiyun.com/carfge/article/details/79691360 https://www.cnblogs.com/fly_dragon/p/8718614.html 1、环境准备 服务器：CentOS 7.3 + ...
Git常见错误
黑曼巴
11-21 325
Cloning into 'kafka231'... remote: Enumerating objects: 3860, done. remote: Counting objects: 100% (3860/3860), done. remote: Compressing objects: 100% (2184/2184), done. error: RPC failed; curl 18 tr...
https:/问题解析remote: Total 10021 (delta 0), reused 0 (delta 0), pack-reused 10021 Receiving objects: 1
xhdll的博客
05-03 1751
https://github.com/hyperledger/fabric-samples.git下载问题解析
git push 失败问题如何解决
haifengbin1989的专栏
03-06 7526
问题：在修改完文件向github提交的时候，提交失败；由于之前直接在github上修改文件提交了一次，但是没有修改对，又再本地修改再次提交，就会失败，报如下错误： hfzhang@010YS-IT-00368 MINGW64 /d/JAVA-01/JAVA-01/Week_07 (main) $ git push origin To github.com:areyoucreazy/JAVA-01.git ! [rejected] main -> main (fetch first)
remote: 此仓库的限制大小为: 2048 MB, 您的使用已经超出限额
studyvcmfc的专栏
06-10 1122
Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 392.33 MiB | 7.45 MiB/s, done. Total 6 (delta 4), reused 0 (delta 0), pack-reused 0 remote: 此仓库的限制大小为: 2048 MB, 您的使用已经超出限额 remote: error: hook declined to update refs/heads/master To https
git学习笔记整理-6-远程仓库
兴华的博客
08-09 295
运行 git remote 命令，它会列出你指定的每一个远程服务器的简写 指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL。 $ git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/tic
git技巧：综合
xhl_will的博客
12-27 1420
查看git版本 $ git --version git version 1.7.11.msysgit.1 查看git所有配置项 $ git config -l core.symlinks=false core.autocrlf=true color.diff=auto color.status=auto color.branch=auto color.interactive=tr
MTK编译Can't call method "version" 问题与解决
虫写的专栏
09-05 1603
MTK编译环境搭建遇到的问题与解决  按照教程装好了RVCT3.1，Perl5.8.8。之前电脑上已装好EXCEL2013所以就没再重复安装了，但是编译时报以下错， Can't call method "version" on an undefined value at tools\chk_env.pl line 387. make: *** [ckmake] Error 9 Error: c...
Linux 常用命令分类详解
最新发布
taotiezhengfeng的博客
12-05 1029
本文总结了Linux常用命令手册，涵盖文件和目录操作、权限管理、系统监控、进程控制、文本处理、压缩归档、用户管理、软件包安装、网络操作等核心功能。重点包括：目录导航（cd/ls）、文件操作（cp/mv/rm）、权限设置（chmod/chown）、进程管理（ps/kill）、文本处理（grep/awk/sed）、压缩解压（tar/gzip）等实用命令，并介绍了查看帮助文档的方法（man/--help）。这些命令组合使用可完成日常系统管理、文件处理和网络操作等任务。
所以较好的步骤是 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
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值