如何用Git将本地代码上传到远程服务器，远程仓库怎么推代码？

把本地代码上传到远程服务器，核心就三步：在本地仓库关联远程仓库地址，用git push把分支推上去，首次推送时加上-u参数锁定上游分支。这篇文章把这套流程拆开揉碎，从零开始讲清楚每一步命令的含义，顺带解决你可能会遇到的各种报错，全程基于命令行操作，图形界面工具虽然直观，但命令行能让你真正理解git的工作方式。

git本地代码上传到服务器完整步骤

先确认本地环境,终端里敲git --version，能看到版本号就说明git已经装好，没装的话，Windows用户去git-scm.com下载安装包，macOS用户执行brew install git，Linux用户用apt或yum装就行。

加载中

将本地代码传到远程仓库

咪猫猫咪

222722-

原视频地址

在远程服务器上创建空仓库

远程仓库是代码的”云端副本”，GitHub、Gitee、GitLab都行，如果是自己租的云服务器，也可以手动建一个裸仓库，以GitHub为例，登录后点右上角”+”号，选择”New repository”，填上仓库名，选Private或Public，千万别勾选”Add a README file”，否则本地仓库和远程仓库的初始提交历史会不一致，首次推送很容易冲突。

如果是自建服务器,SSH登录后在指定目录下执行：

cd /home/user/repos
git init --bare project-name.git

裸仓库没有工作区,只存储版本历史，专门用来接收推送。

关联本地仓库与远程仓库

本地项目文件夹里执行git init把它变成git仓库，然后添加所有文件并提交：

git add .
git commit -m "initial commit"

接着把远程地址关联到本地：

git remote add origin git@github.com:你的用户名/仓库名.git

这里origin是远程仓库的别名，完全可以用别的名字，但origin是全世界git用户的默认习惯，使用SSH地址能免去每次输入密码的麻烦，前提是你已经把SSH公钥配置到GitHub后台，公钥生成方式：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

一路回车后,把~/.ssh/id_rsa.pub复制到GitHub的SSH Keys页面。这一步做完再执行push，就不会每次都被要求输账号密码了，如果你用的是公司内部GitLab或者云服务器的自建仓库，需要先把SSH公钥添加进对应平台的设置里这步别着急，确认公钥已粘贴成功再继续。

首次推送设置上游分支

核心命令长这样：

git branch -M main
git push -u origin main

-M参数把本地分支重命名为main，与远程仓库默认分支保持一致，现在GitHub新建仓库默认分支是main，但很多老教程还在用

master，两者差别不大，只是社区默认值变了统一命名能在后续操作里少踩很多坑。

-u参数的作用是建立本地分支与远程分支的追踪关系，相当于告诉git：以后在这个分支上只需要敲git push或git pull，系统会自动识别该推送或拉取哪条远程分支，没有-u，每次推送都得完整输入git push origin main，麻烦且容易出错。

执行完这步,命令行会显示一行进度条，最后出现main -> main这样的输出，就说明代码已经成功推送到远程服务器了，登录仓库页面刷新一下，代码文件映入眼帘。

之后每次改完代码,推送流程缩减为：

git add .
git commit -m "描述这次改动"
git push

因为追踪关系已经绑定,不用再写origin main。

git push和git pull的区别是什么

把代码放上远程服务器只是起点,日常开发中，你会和这个远程仓库反复打交道，搞清楚push和pull的差异至关重要。

两个命令的角色分工

git push负责”输出”：把本地新建的提交推送到远程。git pull负责”输入”：把远程新增的提交拉取到本地并自动合并，一个上传、一个下载，方向完全相反。

团队协作场景里,行业共识认为最合理的操作顺序是：动手改代码之前先pull一次，把队友的新提交拉下来；改完之后commit，再push上去，这个习惯能避免大量冲突。

日常更新代码的正确顺序

假设你和同事共同维护一个项目,他的代码已经推到远程，你本地还停留在旧版本，直接改代码会以过期内容为基础，产生的冲突概率极高，正确做法：

git pull origin main
git add .
git commit -m "自己的改动"
git push

先pull让本地仓库对齐到最新状态,再改代码、提交、推送，这套流程能用一次pull动作明确”本地需要同步的增量”，同时用一次push明确”远程需要接收的增量”两条路各自清晰，是避免和队友互相覆盖代码的最直接保障。

如果pull之后发现改动了同一个文件的同一行,git会报CONFLICT错误，提示你手动解决冲突，打开文件，找到<<<<<<<、、>>>>>>>标记，保留你需要的代码，删掉标记，再add和commit一次，走完这套操作后重新push，冲突就算平了，大多数学生和团队开发者的日常状态，其实都处于”拉取修改提交推送”的循环里；对刚学会用git的人来说，能跑通这个循环就比背十条命令都有用。

git push origin master什么意思

新手时常在网上看到这条老命令,但又不敢直接敲担心master这个词是不是过时了，会不会报错，拆开看，一点都不神秘。

push命令的三段式结构

git push、origin、master是三段独立信息：git是命令本身，origin代表目标远程仓库，master是目标分支名，整句话的意思是”把本地当前分支推送到名为origin的远程仓库的master分支上”。

如果你的本地分支叫main，远程分支也叫main，那么命令自然变成：

git push origin main

所以git push origin master不是固定搭配，只要把master替换成你的远程仓库实际存在的分支名即可，旧教程喜欢用master，因为那是早期git的默认分支名。现在新建的仓库基本都用main，网上那些写master的老命令照抄当心推错分支。

分支名不对导致的常见报错

如果你在本地执行：

git push origin master

但远程仓库根本没有master分支，git会提示src refspec master does not match any，这不是你的代码坏了，只是分支名对不上，把master换成main，或者用git branch -M master先把本地分支改名，再执行一次就能成功。

同理,如果远程仓库分支太多，你不知道该往哪个推，用git branch -r能列出所有远程分支名，看图说话就行这条排查思路加上前面的改名方法，基本能覆盖大半推送失败的场景。

git私有仓库价格与国内服务器选择建议

对个人开发者来说,仓库是公开还是私有，直接关系到代码安全性，公开仓库谁都能看，私有仓库只有你和协作者能访问。

主流Git托管平台对比

三个平台各有侧重,适用场景不同。

据统计,GitHub注册开发者数量已经相当庞大，是目前全球代码托管的事实标准，但是国内网络访问GitHub不算稳定，推送大仓或频繁交互时会有明显延迟，国内开发者选择云服务器或Gitee这类国内平台的比例近年也在攀升如果你主要在国内活动，优先考虑网络体验；如果目标是开源项目、国际协作，GitHub仍然是第一选择。

自建Git服务器要花多少钱

面向私有仓库,很多中大型团队更信任自建方案，代码数据完全掌握在自己手里，自建Git服务器通常由云服务器和GitLab社区版组成，这套组合的成本本身很低硬件按年付费，整体开销远低于商业托管计划的报价，前提是你愿意花时间维护，云服务器用最低配的云实例，系统装Ubuntu或CentOS，然后一键安装GitLab社区版，通过apt或yum直接部署，基本能跑得很稳，如果团队不到十人，甚至可以直接用git init --bare做一个裸仓库，配合SSH访问，零成本搞定。

这个选择的价值在于：托管平台无法承诺代码永不丢失，而自建仓库的备份策略完全由自己掌控，不过需要提醒的是，自建方案对你的运维能力有要求git服务器本身不出问题，但服务器断电、硬盘损坏、系统崩溃，都会导致你的代码仓库不可用，绝大多数团队和个人开发者，用免费平台就够了；纠结怎么选的话，先问自己三个问题：代码需要私密吗？队友主要在哪个网络环境？有没有专人维护服务器？答案清楚了，选哪条路也就清楚了。

git上传代码常见问题排查

报错1：Permission denied (publickey)
SSH密钥没配好，检查本地是否有密钥，公钥是否已粘贴到GitHub或Gitee后台，执行ssh -T git@github.com测试连接，能收到问候语就说明通了，这个命令是GitHub官方支持的连接测试方式，输出类似”Hi 用户名”的文本就说明SSH认证链路已经打通。

报错2：failed to push some refs to remote
本地提交历史与远程仓库不一致，常见于远程仓库里有README或license文件，而本地仓库没有，解决办法是：

git pull --rebase origin main
git push

--rebase会把本地提交”叠放”到远程最新提交之上，保持线性历史，执行pull之后，本地会自动归拢到和远程一致的内容上，冲突会当场显示，逐个修复即可。

报错3：Updates were rejected because the remote contains work that you do not have locally
这句英文其实在说：远程仓库有本地没有的提交，跟报错2的成因基本一样，解决思路也一致，先拉取再推送，顺序千万别反过来。

推荐一个万能的检查命令：

git remote -v

看输出里有没有origin对应的URL，如果输出为空，说明远程仓库地址还没有配置，回到前面重新执行git remote add origin这步即可。