git客户端上传到服务器端的核心操作是:本地提交后,用git remote add关联远程仓库,再执行git push把分支推送到服务器端。 无论是GitHub、Gitee、GitLab,还是自建裸仓库,流程都围绕“提交关联推送”三步展开,下面按不同场景拆解。
git客户端怎么上传到服务器端:先搞清“服务器端”是谁
很多人卡住不是命令不会,而是没分清服务器端到底是托管平台还是自建主机,托管平台如Gitee、GitHub、GitLab,服务器端由平台维护;自建服务器则是一台你能SSH登录的Linux主机或Windows Server,两者上传路径不同。
本地git仓库推送到远程服务器教程?先记住五个命令
假设你本地已经有一个项目文件夹,还没初始化Git:
cd /path/to/project git init git add . git commit -m "first commit" git remote add origin <远程仓库地址> git push -u origin master
如果远程默认分支是main,就把master换成main。-u的作用是记住关联,下次直接git push。
远程仓库地址有两种常见形式:
- SSH:
git@github.com:user/repo.git或ssh://user@server:22/path/repo.git - HTTPS:
https://gitee.com/user/repo.git
SSH更安全,适合长期使用;HTTPS更容易穿过防火墙,但每次可能要输令牌。
git上传到服务器需要什么权限?
权限问题经常被忽略,自建服务器上,你需要对裸仓库目录有写权限,比如用git init --bare /srv/repo.git创建后,要确保运行SSH的用户能写入该目录:
chown -R git:git /srv/repo.git chmod -R 755 /srv/repo.git
托管平台则要求你的账号拥有该仓库的写权限,如果开启了双因素认证,HTTPS方式需要输入个人访问令牌,而不是登录密码,SSH方式需要把本地公钥~/.ssh/id_rsa.pub添加到平台或服务器的authorized_keys中。
| 服务器类型 | 上传方式 | 权限要点 |
|---|---|---|
| Gitee/GitHub/GitLab | SSH或HTTPS | 仓库写权限、令牌或公钥 |
| 自建裸仓库 | SSH | 用户对仓库目录有写权限 |
| 内网Git服务 | HTTP/SSH | 网络可达、账号权限 |
托管平台与自建服务器,上传路径差在哪
托管平台省去了服务器维护,适合大多数个人和中小团队,自建服务器可控性强,但需要自己处理SSH、防火墙、备份和权限,近年来,国内不少团队选择简米云、酷番云等云主机搭建Git服务,安全组要放行SSH端口,否则本地推送会超时。
| 对比项 | 托管平台 | 自建服务器 |
|---|---|---|
| 初始成本 | 免费私有仓库可用 | 需要服务器和运维 |
| 上传复杂度 | 低,注册即用 | 中,需配置SSH和仓库目录 |
| 数据控制 | 平台托管 | 完全自主 |
| 适合场景 | 个人、小团队、开源 | 内网、强合规、定制化 |
Windows下git客户端上传到服务器与Linux环境有哪些不同
本身就是搜索词,Windows和Linux在Git操作上大体一致,但细节容易踩坑。
换行符处理
Windows默认换行符是CRLF,Linux是LF,如果团队混合使用,建议设置:
git config --global core.autocrlf true # Windows git config --global core.autocrlf input # Linux/macOS
否则可能出现“整个文件被修改”的假象。
凭据管理
Windows下推荐安装Git for Windows,自带Git Bash和凭据管理器,第一次用HTTPS推送时,会弹窗要求输入用户名和令牌,保存后后续不用重复输入,Linux下可以用git config --global credential.helper store,但明文保存有安全风险,更推荐SSH密钥。
路径与大小写
Windows路径不区分大小写,Linux区分,如果仓库里有两个文件仅大小写不同,在Windows上可能只能看到一个,上传前最好检查文件名。
操作对比表
| 对比项 | Windows | Linux |
|---|---|---|
| 终端 | Git Bash、PowerShell | Bash、Zsh |
| 换行符 | CRLF | LF |
| 凭据管理 | 凭据管理器 | SSH agent、credential store |
| 权限模型 | 较宽松 | 文件权限严格 |
| 常见问题 | 路径反斜杠、换行符 | 权限拒绝、SSH密钥权限 |
git push上传到服务器失败怎么办?常见错误与排查思路
推送失败不是世界末日,多数情况有明确原因。
rejected - non-fast-forward
远程分支有你本地没有的提交,比如同事已经推了新代码,你直接推会被拒绝,解决:
git pull --rebase origin main # 解决冲突后 git push origin main
不要一上来就git push -f,强制推送会覆盖远程历史,团队协作中慎用。
Permission denied (publickey)
SSH密钥没配对,检查:
ssh -T git@github.com ssh -T git@gitee.com
如果提示失败,重新生成密钥并添加到平台,自建服务器则检查~/.ssh/authorized_keys权限,通常要求600。
remote: HTTP Basic: Access denied
HTTPS方式下密码或令牌错误,Gitee、GitHub现在都要求使用个人访问令牌,去账号设置里生成令牌,勾选仓库读写权限,再用令牌代替密码。
failed to push some refs
往往和分支名不匹配有关,本地是master,远程默认是main,可以先查看远程分支:
git branch -r git remote show origin
然后重命名本地分支或推送时指定:
git push -u origin master:main
自建服务器报insufficient permission
检查仓库目录属主和权限,如果服务器端用git用户运行,而仓库属于root,就会写不进去,用chown修正。
从零开始:把本地项目上传到远程服务器的完整操作路径
下面给出一条可验证的路径,适合自建服务器和托管平台。
自建裸仓库场景
在服务器上:
ssh user@your-server mkdir -p /srv/git/myproject.git cd /srv/git/myproject.git git init --bare exit
回到本地:
cd /path/to/myproject git init git add . git commit -m "初始化项目" git remote add origin ssh://user@your-server:22/srv/git/myproject.git git push -u origin master
如果服务器SSH端口不是22,写实际端口,例如ssh://user@your-server:2222/srv/git/myproject.git,国内服务器如简米云、酷番云,安全组要放行对应端口。
托管平台场景
在Gitee或GitLab上新建空仓库,不要勾选“初始化README”,然后本地:
git init git add . git commit -m "首次提交" git remote add origin git@gitee.com:yourname/myproject.git git push -u origin main
如果推送时提示分支不存在,先git branch -M main把本地分支改成main。
HTTPS与SSH两种上传方式怎么选
HTTPS上传步骤
- 在平台创建仓库,复制HTTPS地址。
- 本地执行
git remote add origin <HTTPS地址>。 - 推送时输入用户名和个人访问令牌。
- 如果不想每次输入,可配置凭据管理器。
SSH上传步骤
- 本地生成密钥:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"。 - 将
~/.ssh/id_rsa.pub内容添加到平台SSH公钥设置。 - 测试连接:
ssh -T git@gitee.com。 - 使用SSH地址关联远程仓库并推送。
验证上传结果
推送成功后,在服务器端或平台页面查看提交记录,自建服务器可以用:
git --git-dir=/srv/git/myproject.git log --oneline
能看到提交哈希,说明上传成功。
团队协作场景下git上传到服务器的分支策略
一个人写代码和一群人写代码,上传策略完全不同,行业共识认为,Git已成为分布式版本控制的事实标准,团队中推荐:
main或master:稳定分支,只接受合并请求develop:日常集成feature/xxx:功能分支,完成后合并到develophotfix/xxx:紧急修复
上传前先拉取:
git checkout develop git pull origin develop git checkout -b feature/login # 开发并提交 git push -u origin feature/login
然后在平台上发起合并请求,保护分支可以防止直接推送,减少误操作。
对于小团队,如果不想自建GitLab,用Gitee或GitHub的免费私有仓库也能满足需求,业内专家指出,推送前先拉取远程变更,能显著减少冲突和返工。
git客户端上传到服务器端并不复杂,核心就是本地提交、关联远程、推送分支,把权限、分支名和网络这三个变量控制好,绝大多数上传问题都能快速解决。
关于git客户端上传到服务器端的常见疑问
Q1:git客户端上传到服务器端必须用命令行吗?
不是,TortoiseGit、SourceTree、GitKraken、VS Code内置Git都能完成上传,图形化客户端底层调用的还是git push,理解命令有助于排查错误。
Q2:上传到服务器后,本地再修改怎么同步?
再次执行git add .、git commit -m "说明"、git push即可,如果远程有新提交,先git pull --rebase再推送。
Q3:git push会覆盖服务器上的代码吗?
普通推送不会覆盖远程已有提交,只会追加新提交,如果远程分支有你本地没有的提交,推送会被拒绝,只有使用git push -f强制推送才会覆盖远程历史,团队协作中应避免对公共分支使用强制推送。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/702915.html




