把本地项目推送到远程 Git 服务器的核心操作只有三步：先在服务器创建空仓库，再在本地关联远程地址，最后执行 push 命令，整个过程熟练后不超过五分钟。
很多开发者初次接触 Git 时，容易被各种术语绕晕，其实不用管那些复杂的工作流理论，你只需要理解一个朴素的场景：你手里有一份写好的代码，想把它完整地搬到一个远程的“仓库房间”里，并且以后每次改动都能同步过去，这篇文章会把你当成一个刚入行的同事,手把手带你把这条上传链路跑通。
推送前必须搞清楚的三种连接方式和适用场景
在动手敲命令之前，先花两分钟确认你面对的是哪种服务器环境，不同的环境，初始化方式有天壤之别,选错了方向会让后续操作变得拧巴。
第一种是 GitLab 或 GitHub 这类代码托管平台。 你只需要在网页端点几下按钮，创建一个空项目，然后本地按提示操作即可，这类平台最常见的连接方式是 HTTPS 和 SSH，HTTPS 每次推送需要输入账号密码，SSH 则通过密钥对认证，配置一次后终身免密，行业共识认为，SSH 是体验最顺畅的方式。
第二种是你自己买的云服务器。 比如简米云、酷番云的 ECS，你需要自己在服务器上安装 Git，并用 git init --bare 命令创建一个裸仓库，裸仓库没有工作目录，只存放版本历史,这是专门用来接收推送的标准做法。
第三种是公司内网搭建的 Gerrit 或 Gitea。 这种环境的权限控制一般更严格，通常要求你先在平台上上传 SSH 公钥，再由管理员分配项目权限，如果你拿到的是一个类似 ssh://git@192.168.1.100:29418/project.git 的地址，直接把它当作 remote 地址即可。
第一步：在本地生成 SSH 密钥并完成配对
SSH 密钥就像是你进出服务器大门的身份证，不管你面对的是 GitHub 还是自己的云主机，都需要先在本地生成这对钥匙，打开终端（Mac 和 Linux 用户用自带的 Terminal，Windows 用户建议用 Git Bash）,输入以下命令：
ssh-keygen -t rsa -b 4096 -C "你的邮箱"命令执行后，系统会提示你选择保存路径和设置密码短语，路径直接按回车选默认即可，密码短语可以留空，生成完成后，你会得到两个文件：id_rsa（私钥，打死都不能给别人看）和 id_rsa.pub（公钥，需要放到服务器上）。
Mac 用户注意，如果你的电脑安装了多个 Git 版本,建议先确认一下当前用的是哪个：
which git如果显示的是 /usr/bin/git，说明用的是系统自带版本，没问题，如果显示的是 Homebrew 安装的路径，后续操作也没差别,密钥配置方法完全一致。
接下来查看你的公钥内容：
cat ~/.ssh/id_rsa.pub把这串以 ssh-rsa 开头、以邮箱结尾的字符全部复制，然后登录你的 Git 服务器，找到 Settings -> SSH Keys 或者 个人设置 -> SSH 公钥 的入口,把内容粘贴进去保存。
Windows 用户可能会遇到一个坑：如果你的用户名包含中文，~/.ssh 目录可能无法被 Git 正确解析，遇到这种情况，可以在 Git Bash 中手动指定路径：
export HOME="C:/Users/你的用户名"然后重新生成密钥,确保密钥文件生成在这个目录下。
第二步：在远程服务器上建立仓库地基
远程仓库的创建方式取决于你用的是托管平台还是自建服务器，如果使用 GitHub/GitLab，操作路径非常直观：点击右上角的 New repository（或 新建项目），输入项目名称，注意不要勾选 “Initialize this repository with a README” 选项，勾选了 README 会让仓库带有一个初始提交，这会导致你本地的历史与远程历史不一致，首次 push 时就会报 “failed to push some refs” 的错误。
如果是自建服务器,登录到服务器上执行：
mkdir /var/git/project.git
cd /var/git/project.git
git init --bare这里要特别说明，git init 和 git init --bare 是两回事，前者创建的是带工作区的普通仓库，用于本地开发；后者创建的是中央裸仓库，用于接收推送，一旦用错，推送时会出现 “ refusing to update checked out branch” 的报错。
第三步：本地仓库初始化与 remote 配置
现在回到你的本地项目目录，如果你的项目目录还不是 Git 仓库,先执行：
git init然后添加远程地址，以 GitHub 为例,地址有两种格式：
HTTPS格式：https://github.com/你的用户名/project.git
SSH格式：git@github.com:你的用户名/project.git推荐使用 SSH 格式，因为 HTTPS 格式在推送时每次都要输入密码,执行：
git remote add origin git@github.com:你的用户名/project.git添加完成后，可以用 git remote -v 查看远程地址是否配置正确，如果发现地址写错了，用 git remote set-url origin 正确地址 改正。
多人协作场景下尽量别用 master 作为主分支名，因为近些年很多平台默认分支已经改成了 main，为了减少不必要的麻烦,建议在本地就统一好分支名：
git branch -M main如果你想了解新项目用 Git 管理文件的基本流程，这里的核心操作便是先 git add 将工作区文件暂存，再 git commit 提交到本地仓库，git push 推送到远程。
第四步：执行 add、commit、push 三连击
接下来就是正式上传了，先把项目中的文件加入暂存区，这里有个高频操作细节：强烈建议你在项目根目录创建 .gitignore 文件，把 node_modules、target、.idea 这类依赖或编译产物排除在外，否则你会上传一大堆根本不需要的文件，既拖慢推送速度,也让仓库显得杂乱。
.ignore 文件内容示例：
node_modules/
dist/
target/
.idea/
.log然后执行暂存和提交：
git add .
git commit -m "Initial commit: 项目初始化"如果项目文件太多，提交时提示 hint: Waiting for your editor to close the file 卡住了，说明 Git 默认打开了 Vim 编辑器等待你输入提交信息，此时输入 wq 回车即可退出，为了避免每次都被 Vim 卡住，可以设置默认编辑器为 VS Code：
git config --global core.editor "code --wait"最后推送：
git push -u origin main加 -u 参数是为了把本地 main 分支与远程 main 分支建立关联，之后你就可以直接使用 git push 和 git pull,无需再加参数。
git push origin master 时报错怎么办
新手最容易碰到的报错就是推送被拒绝，显示 error: failed to push some refs to，这句话的意思是远程仓库存在你本地没有的提交,常见原因有两种：
远程仓库创建时勾选了 README 或 .gitignore 选项。 这时远程有一个基于空仓库的初始提交，而你本地是基于空仓库的另一个提交，两者没有共同祖先,解决办法是先把远程内容拉取下来并合并：
git pull origin main --allow-unrelated-histories然后执行 git push -u origin main 即可。
自己之前在网页端误提交了文件。 如果确认远程上的文件确实没用,可以强制覆盖：
git push -f origin main但这里要提醒你：-f 参数慎用，它会强制重写远程提交历史，如果项目里有其他协作者，他们的本地历史会与远程分叉，清理起来非常麻烦，多人项目不要用,宁可先把远程分支删除再重新推送。
如何用 git 上传项目到服务器并保持后续同步
首次上传成功后，日常的同步操作就非常简单了,你只需要记住两条命令：
git add .
git commit -m "描述这次改了什么"
git push如果你修改了很多文件，想快速查看哪些文件改动了，用 git status，如果你想把已提交的单个文件保留在本地、但不纳入版本控制，需要执行 git rm --cached 文件名。
提交频率的拿捏：业内专家指出，提交粒度应该以“一个逻辑功能”为单位，比如修复了一个 bug，提交一次；添加了一个新页面，提交一次，不要在代码里揉杂十几个不相关的改动再一次性提交,这样后续回溯问题时会非常困难。
关于分支策略，很多团队采用 Git Flow 或者 GitHub Flow，如果你是一个人开发，直接在 main 分支上提交完全没有问题，如果是多人协作，建议遵循一个简单的规则：不要直接往 main 推，先拉一个 feature 分支，开发完再合并,具体操作是：
git checkout -b feature/你的功能名这个命令会创建一个新分支并切换过去，你在这个分支上的提交不会影响主分支，开发完成后，切换回 main，合并分支,推送：
git checkout main
git merge feature/你的功能名
git push本地仓库推送到远程仓库时出现 permission denied 的排查思路
permission denied (publickey) 这个报错几乎所有人都会遇到，看到这个提示,先自查三个位置：
检查密钥文件是否存在，如果你换过电脑或者重装过系统，密钥文件在 ~/.ssh 目录下找得到吗？找不到就重新生成一份,然后去服务器后台把新的公钥替换掉旧公钥。
检查远程地址是否采用了 SSH 格式，有人会犯把 HTTPS 地址和 SSH 密钥混用的错误，执行 git remote -v 看输出，如果地址以 https:// 开头，就说明你本地还是走 HTTPS 协议,执行：
git remote set-url origin git@github.com:你的用户名/project.git检查公钥是否完整粘贴，复制公钥时，确保把整个 ssh-rsa 到邮箱结尾的全部字符都复制了,不要漏掉开头或者多了换行符。
检查网站后台是否填错了公钥框，GitHub 的 SSH Keys 设置在 Settings -> SSH and GPG keys 页面，如果你用的是 GitLab，路径是 Preferences -> SSH Keys，如果你是公司内网的 GitLab,还需要确认自己的账号有没有被管理员禁用。
如何用 git 上传项目时忽略大文件和敏感信息
一个容易被忽略的问题是误把敏感文件传上去。.env 配置文件里存了数据库密码、API 密钥，一旦推送到远程仓库，即使后来删掉，这些敏感信息也永远留在了 Git 历史里，所以在上传之前，提前规划好 .gitignore 的内容至关重要。
除了 .env 文件,还有几类文件也应该坚决排除：
- 编译产物：
dist、build、.class - 依赖目录：
node_modules、vendor - IDE 配置文件：
.idea、.vscode（团队统一配置除外） - 系统文件：
.DS_Store、Thumbs.db - 日志文件：
.log
如果你不小心把一个大文件推上去了，而且后续不想让它成为仓库的负担，Git 官方推荐的方案是使用 git filter-repo 工具清理历史，这个操作涉及改写历史，建议在离线状态下执行,并且需要团队一致配合。
另一个常见需求是上传超过 100MB 的大文件，普通 Git 仓库对单个文件的大小有限制，GitHub 限制单个文件 100MB，超过这个限制你需要使用 Git LFS（Large File Storage），如果你想省钱，这里有个相对靠谱的方案：将大文件放在对象存储（如简米云 OSS、酷番云 COS），然后在仓库里放一个下载脚本，让使用者自行拉取，这样既保持仓库轻量，也不用额外买 Git LFS 的存储空间。
常见问题 Q&A
本地项目已经推送到 GitHub，怎么换成 Gitee 的地址？
执行 git remote set-url origin git@gitee.com:你的用户名/project.git 即可替换，替换后执行 git push -u origin main 推送，如果你想同时推送到两个平台，可以添加第二个远程地址：git remote add gitee git@gitee.com:你的用户名/project.git，推送时用 git push gitee main。
推送到一半断网了，项目会不会处于损坏状态？
不会，Git 的推送过程是原子的，服务器只有在完整接收所有对象后才会更新引用，断网后重新执行 git push 即可，Git 会从断点继续传输未完成的对象,不会产生重复或损坏的历史记录。
不小心把不该提交的文件推送到了远程，怎么彻底移除？
如果文件在最新提交中，直接从 .gitignore 中添加排除规则，然后执行 git rm --cached 文件名、提交并推送，远程文件会被移除，但仍保留在历史中，如果敏感信息已经泄露，需要执行 git filter-repo 清除历史，或者直接删除远程仓库重新创建,然后强制推送全新历史。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783994.html
