从零开始：用 Git 命令完成首次项目推送（及常见报错解决）

作为日常使用 Visual Studio 的开发者，我一直习惯于 IDE 内置的 Git 图形化操作。直到有一天，我决定在 GitHub 上创建自己的项目仓库（是的，你没有看错，是自己的项目，没想到有一天我也可以成长到能拥有自己的开源项目，咳咳，跑题了）。

嗯，那么，本着"古法编程"的自我驱动，我决定一定要用纯命令行来完成 Git 工作流。本文记录了我从初始化到成功推送的完整过程，以及途中遇到的一个典型报错及其解决方案，希望对同样从 GUI 转向命令行的朋友有所帮助。

准备工作：配置身份信息

根据官方文档（Pro Git 书）的指引，第一步是设置全局用户名和邮箱，这是 Git 提交记录的基础信息。

bash

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

💡 这些信息会附加在每次提交中，请确保与远程仓库（如 GitHub）绑定的邮箱一致。

一、初始化本地仓库

进入项目根目录，执行：

git init

这会在当前文件夹下创建一个 .git 子目录，用于存放版本库数据。

二、关联远程仓库

为了将本地代码推送到 GitHub，需要添加远程仓库地址，并给它起一个别名（通常叫 origin）：

git remote add origin https://github.com/你的用户名/项目.git

检查添加是否成功：

git remote -v

输出应显示 fetch 和 push 的 URL，确认无误即可。

三、添加文件到暂存区

在正式添加之前，强烈建议先创建 .gitignore 文件，排除不需要版本控制的文件（如编译输出、临时文件等）。对于 Visual Studio 项目，常见的忽略项包括：

bin/
obj/
.user
.suo
packages/

然后将所有文件加入暂存区：

git add .

如果想查看具体哪些文件被添加，可以用 git status 检查。

四、提交到本地仓库

使用 commit 创建第一个本地提交：

git commit -m "Initial commit"

良好的提交信息有助于日后追溯，建议简洁但明确。

五、推送到 GitHub（我期待中的情况）

在推送之前，需要确认本地和远程的分支名称。GitHub 新建仓库时默认主分支为 main，而本地 git init 默认分支可能是 master（取决于 Git 版本配置）。

查看当前本地分支：

git status

输出第一行会显示 On branch master 或 On branch main

方案一：将本地分支重命名为 main 并推送

git branch -M main # 重命名当前分支
git push -u origin main # -u 建立上游跟踪，后续只需 git push

方案二：保持本地分支为 master，直接推送到远程的 main

git push -u origin master:main

如果远程仓库是空的（未勾选"Initialize with README"），上述命令会成功，之后日常使用 git push 即可。

⚠️ 遭遇报错：远程已有初始提交

然而，我在推送时遇到了如下错误：

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.

为什么本地分支会"落后"于远程？明明远程是我刚创建的。原因是我在创建仓库时勾选了"Initialize this repository with a README"，这导致远程仓库已经有一个独立的初始提交，而本地没有任何提交历史与之关联，Git 默认拒绝推送以防止覆盖远程内容。

啊啊啊！我开始怀念 Visual Studio 的 GUI 工具了。

解决方案：合并无关历史

我们需要拉取远程的初始提交并与本地历史合并。由于二者没有共同祖先，必须添加 --allow-unrelated-histories 选项：

git pull origin main --allow-unrelated-histories

说明：无论你当前的本地分支叫 master 还是 main，该命令都会拉取远程 main 分支并合并到当前分支。合并完成后，本地分支将与远程历史建立关联。

如果出现冲突（例如 README 文件内容不同），请手动编辑冲突文件，保留需要的内容，然后：

git add .
git commit -m "Merge remote initial commit"

💡 关于 Vim 编辑器的特别提示：

执行 git commit 后，如果系统弹出了一个满是英文的 Vim 界面（黑色背景，底部有冒号），不要慌！

  • 这是 Git 让你确认合并提交信息。
  • 直接输入 :wq（冒号+w+q）然后按回车，即可保存并退出。
  • 如果不想写长篇大论，保持默认的合并信息直接退出就行，Git 会自动记录你合并了远程分支。

最后推送：

git push origin main

如果你的本地分支是 master，但推送目标为远程 main，也可以使用 git push origin master:main 显式映射，效果相同。

大功告成！此时在 GitHub 上可以看到本地代码已成功推送，且保留了 README 的历史记录。

💡 进阶建议与注意事项

  1. 优先使用 --rebase 保持历史线性
    如果希望避免多余的合并提交，可使用 git pull --rebase origin main。但注意 rebase 会改写本地提交历史，在多人协作的公共分支上使用时需谨慎（需与团队达成共识）。

  2. 认证问题
    使用 HTTPS 推送时可能要求输入用户名和密码（现在 GitHub 需使用个人访问令牌）。建议配置 SSH 密钥或使用 Git 凭证管理器以简化操作。

  3. 验证推送结果
    推送后，可用以下命令查看提交历史图，确认本地与远程一致：

    git log --oneline --graph --all

  4. 绝不滥用强制推送
    有些人会尝试 git push -f 强行覆盖远程，但这会丢失远程已有的提交，在协作项目中极其危险，应尽量避免。

  5. 日常简化流程（修正版）
    后续更新的正确操作顺序是：先拉取最新代码 → 再提交本地更改 → 最后推送。

    bash

    git pull # 1. 拉取远程最新代码
    git add . # 2. 添加修改到暂存区
    git commit -m "message" # 3. 提交到本地仓库
    git push # 4. 推送到远程

总结

这次实战让我学到了几个关键点：

  • 远程仓库若含有初始提交，需要 --allow-unrelated-histories 来合并。
  • 本地与远程分支名可以不同，推送时用 local:remote 指定映射。
  • 合并历史时可能产生冲突，需手动解决。

掌握了这些，您就能自如地用命令行管理个人或团队项目了。如果希望深入了解，推荐阅读 Pro Git 中文版 及 GitHub 官方文档。

希望这个实战记录能帮您避开同样的坑，享受命令行带来的掌控感！ 😄

posted @ 2026-08-02 16:59  御大侠的小小白  阅读(1)  评论(0)    收藏  举报