Git(6)——远程仓库

最新推荐文章于 2025-03-28 08:50:58 发布
原创 最新推荐文章于 2025-03-28 08:50:58 发布 · 358 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#git

创建远程仓库

远程仓库也就是你的代码在网上某个托管（代管）的地方，一般有Github和码云等，github相比码云来说质量等方面都略胜一筹。
但如果没有VPN来加速的话，Pull/Push一些大项目时很费劲。顺便一提，如果你想从github转到码云，码云提供直接克隆仓库功能，具体请自行搜索

创建SSH Key

SSH Key是一串密钥，用来作为本地和远程仓库之间的口令和密码

ssh-keygen-t rsa -C "youremail@example.com"
#这里的email地址应该填的是本地初始化git的时候所填的email，要保证两者一致

输入命令后会有一系列的提问，但一般直接按回车确定即可，则可以在用户目录下（windows和linux都一样）可以找到一个叫.ssh的文件夹（linux下为隐藏文件夹，可以通过ls -a命令来查看），复制其下的id_rsa.pub里的内容并添加到远程仓库的SSH密钥（一般在远程仓库的选项/Setting下可以找到）

你好! Git——远程仓库与本地仓库交互管理
plj521的博客
07-30 1481
前面所说的所有内容（⼯作区，暂存区，版本库等等）， 都是在本地，现在我们学习远程仓库
Git入门——windows环境下git连接github远程仓库
zhen921的博客
02-27 5267
既然使用git了，远程仓库的连接配置是一定要学的，好处也是显而易见的，在我看来远程仓库的好处主要有两点： 一是可以作为本地仓库的一个备份，这样项目会更有保险。 二是有了远程仓库更方便团队的协作开发。 连接远程仓库简单来说四步就够了。 建立本地仓库和远程仓库 本地生成钥匙 把钥匙放到github上 本地连接github 第一步 建立仓库 既然我们要连接远程仓库，那前提是远...
git 的使用(6)-git远程仓库
domorejojo
10-10 1608
前言： git 基本是在用git 掌握了命令基本上也就会说自己会git了。
GIT代码托管
icon_sunshine的博客
06-17 720
以下是一些流行的Git代码管理平台：使用Git代码管理平台通常涉及以下步骤：注意选择代码托管平台时通常会考虑以下因素：
推荐几个常用的Git代码托管平台
无知人生，记录点滴
03-06 2万+
说到Git代码托管平台，首先推荐的是GitHub，好多好的开源项目都来自GitHub，但是GitHub只能新建公开的Git仓库，私有 仓库要收费，如果你做的是一个开源项目，可以首选GitHub。下面推荐几个比较好的Git代码托管平台，这里我不做过多的说明和评价，也好让大家多看 看，比较一下，找到自己的”真爱”。1、GitHub       GitHub 是一个面向开源及私有软件项目的托管平台，因为只
Git 常用操作流程
JoshYueby的博客
12-15 283
添加全局用户名 git config --global user.name "Your Name" 添加全局邮箱 git config --global user.email "YourEmail@example.com" 复制项目地址 从GitHub、GitLab、码云等代码托管平台创建好项目并复制项目地址，或直接从创建好的项目中复制地址 下载该项目（模板）
git代码托管
qq_40863153的博客
10-15 265
目录git创建公匙检查系统是否存在密钥：备份密钥（可选）：生成新密钥：复制密钥：下面以华为云为例绑定公钥新建仓库idea项目绑定 git创建公匙 检查系统是否存在密钥： 运行 Git Bash, 在弹出的终端中输入下面提示的代码 cd ~/.ssh 如果提示：No such file or directory 说明你是第一次使用git需要生成密钥。如果不是第一次使用您可以选择使用已有密钥或者重新生成密钥方式。 备份密钥（可选）： mkdir key_backup cp id_rsa* key_backu
Git·——连接远程仓库
weixin_64942806的博客
08-24 5688
把本地的master分支内容推送的远程origin主机的master分支，并把本地的master分支和远程的master分支关联起来。注意：如果先建立本地仓库，再建立远程仓库，一般本地仓库和远程仓库名称相同。注意：使用该连接方式，推送时，会要求输入gitee的用户名和密码。注意：还可以使用ssh方式连接远程仓库，本例中不再展示。如果没有弹出该页面，可以先删除凭证。推送后，gitee仓库中数据变化。1）使⽤GitLab搭建私服。本例使用码云作为远程仓库。该命令不会自动合并文件。
Git——远程仓库的操作
m0_71678977的博客
03-28 2290
解决方法二：git push <远程主机名> <本地分支名>:<远程分支名> - 注意，也可以使用-u参数，实现方法一一样的效果。# FETCH_HEAD是一个版本链接，记录在本地的一个文件中，指向着目前已经从远程仓库取下来的分支的末端版本，可省略。# 建立本地仓库与远程仓库的连接（联系）- git remote add 远程主机别名 远程主机地址。# 注意：以上的删除只是在本地仓库中删除标签。# 在码云中，README.md是一个特殊的文件，类似网站的默认首页，进入仓库后默认打开此文件。
Git学习——远程仓库（4）
Hoorus的窝
02-12 708
日常学习笔记
Git 进阶 —— 远程仓库
黎明前的沉睡
07-28 278
原文见链接Git 进阶 —— 远程仓库
精选资源
git仓库————迁移脚本
04-14
5. **推送代码**：执行`git push -u origin --all`将本地所有分支推送到新创建的远程仓库。如果需要推送标签，使用`git push --tags`。 6. **迁移Webhooks和CI/CD配置**：Webhooks用于触发外部服务的事件，如自动化...
Git入门——远程仓库及分支管理
贰拾肆樵
02-13 2888
前面提到，Git相对于传统的SVN有着很大的优势，其中之一就在于集中式系统中，版本库只能存在于中央服务器上；而在Git中，版本库可以克隆多个，甚至在同一台主机中也可以克隆多个版本库。当然，日常开发过程中，还是会有一台主机充当中央服务器的角色，作为整个项目的整体基准。我们可以自己搭建一个git服务器，也可以直接使用github所提供的免费仓库托管服务。 在本文中我们使用GitHub。在使用之前，需要注册GitHub账号，并且在本地与GitHub上设置SSH，具体操作请参照
Git(5)——查看修改内容
热门推荐
增强哥哥的BLOG
05-09 4万+
在Git中使用git status等命令来查看文件的变动
Git(4)——把文件添加并提交到版本库
增强哥哥的BLOG
05-09 1762
4.把文件添加并提交到版本库千万不要使用Windows自带的记事本编辑任何文本文件，下载notepad++进行编辑，仅限于windows。编写一个readme.txt文件，内容如下Git is a version control system. Git is free software.一定要放到learngit目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
Git(2)——初始化Git
增强哥哥的BLOG
05-09 430
Git初始化
Git(3)——创建版本库
增强哥哥的BLOG
05-09 409
3.创建版本库版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。1. 首先，选择一个合适的地方，创建一个空目录$ mkdir learngit $ cd learngit $ pwd /Users/michael/learngitpwd命
Git(1)——安装Git
增强哥哥的BLOG
05-09 403
1.安装GitLinux上的安装 可以先在terminal中输入git查看系统中是否已经安装 如果没有安装，执行sudo apt-get install git（ubuntu下）即可安装 如果是其他Linux版本，可以直接通过源码安装。先从Git官网下载源码，然后解压，依次输入：./config，make，sudo make install这几个命令安装就好了。（先cd至压缩后的文件夹） windo
所以较好的步骤是 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、付费专栏及课程。

余额充值