Git怎么创建GitHub仓库_Git关联GitHub远程仓库教程【入门】
Git怎么创建GitHub仓库_Git关联GitHub远程仓库教程【入门】

免费影视、动漫、音乐、游戏、小说资源长期稳定更新! 👉 点此立即查看 👈
想把本地代码推上GitHub,结果命令敲下去不是报错就是没反应?这事儿太常见了。别急,问题往往出在几个关键细节上。下面咱们就把从创建仓库到成功推送的完整链路,以及那些最容易“踩坑”的环节,掰开揉碎了讲清楚。
本地已有项目,怎么关联到 GitHub 新建的远程仓库
核心操作就一条:git remote add。但这里有个至关重要的前提——你得先在GitHub上手动创建一个空仓库。什么叫空仓库?创建时,那个“Initialize this repository with a README”的选项,千万别勾选。一旦勾了,GitHub会帮你生成初始提交,这会导致远程仓库和你的本地仓库拥有不同的起点(commit history),直接推送就会触发冲突。
常见的“翻车”现场有两种:一种是手快重复执行命令,终端冷冰冰地告诉你 fatal: remote origin already exists;另一种更隐蔽,推送时遇到 ! [rejected] main -> main (non-fast-forward),这多半就是远程有文件(比如那个README)而本地没有,历史对不上。
怎么破?按这个顺序来:
- 先看一眼现状:
git remote -v,检查是否已经配置过远程地址。 - 如果“origin”已经存在,别再用
add了,直接用git remote set-url origin <你的仓库URL>替换掉它。 - 第一次推送,记住带上
-u参数:git push -u origin main。这个-u(upstream的缩写)能帮你建立追踪关系,以后在这个分支上直接git push就行。对了,注意分支名现在默认是main,不是以前的master了。 - 万一手滑,已经在GitHub仓库初始化了README怎么办?也有救。先执行
git pull --allow-unrelated-histories origin main,把两个不相关的历史合并一下,然后再推送。
从零开始:本地没 Git 仓库,怎么同步到 GitHub
这种情况更简单,本质就是本地初始化和关联远程两步走。任何一步漏了,都会卡在“没有upstream分支”或者push了像没push一样。
适合什么场景呢?比如你刚写了个新脚本的目录、下载了一个开源项目模板想自己改改,或者决定把一个老项目纳入版本管理。
操作流程是一条直线:
- 进入你的项目根目录,运行
git init,把这个文件夹变成Git能管理的仓库。 - 把文件加入暂存区:
git add .(这个点号代表当前目录所有文件),或者更精确点,git add README.md只加特定文件。 - 创建第一次提交:
git commit -m "init",给这次提交起个名字。 - 此时再去GitHub页面,创建一个空仓库,拿到它的HTTPS或SSH地址(格式类似
https://github.com/用户名/仓库名.git)。 - 最后关联并推送:
git remote add origin 你的仓库URL,紧接着git push -u origin main。
git push 报错 “Authentication failed”,怎么解决
这可能是近年来最高频的报错了。根源在于GitHub从2021年开始,彻底禁用了直接用账号密码通过HTTPS认证的方式。所以,不是你密码错了,而是认证方式压根不对。
现在GitHub只认两样东西:Personal Access Token(个人访问令牌)或者SSH密钥。
- 方案一:HTTPS + PAT(推荐给大多数用户)
去GitHub设置里生成一个Token,生成时至少勾上repo权限。然后,在关联或推送时,把远程地址里的密码部分换成这个Token,格式像这样:https://<你的token>@github.com/用户名/仓库.git。系统会把这个Token当作密码来验证。 - 方案二:配置SSH(一劳永逸)
在本地生成SSH密钥对:ssh-keygen -t ed25519 -C "你的邮箱"。然后,把生成的公钥文件(通常是id_ed25519.pub)里的全部内容,复制粘贴到GitHub个人设置的“SSH and GPG keys”页面里。
接着,把本地仓库的远程地址换成SSH格式:git remote set-url origin git@github.com:用户名/仓库.git。
最后测试一下:ssh -T git@github.com,如果看到“Hi 用户名!”,恭喜,通道打通了。
为什么 git clone 下来的项目,改完 push 不报错却没更新 GitHub 页面
这种感觉最让人困惑:命令执行了,也没红字报错,但GitHub上就是纹丝不动。问题通常出在两个地方。
首先,最可能的原因是:你只改了文件,但没提交。Git推送的是“提交”(commit),不是工作区里那些还没保存的快照。没执行git add和git commit,改动就只留在你本地电脑上,推不上去。
其次,一个非常隐蔽的坑是分支名不匹配。GitHub默认的主分支名叫main,但你本地克隆下来的老项目,或者你本地初始化生成的分支,可能还叫master。当你执行git push origin main时,代码确实推上去了,但可能推到了一个全新的、名叫main的分支上,而网页默认展示的却是那个旧的、没变动的master分支。
排查和解决步骤:
- 查看本地分支:
git branch,前面带星号(*)的就是你当前所在的分支。 - 查看详细追踪关系:
git branch -vv,能看到本地分支跟踪的是哪个远程分支。 - 如果本地是
master,但想推送到远程的main,有两个办法:要么把本地分支重命名:git branch -M main;要么在推送时指定映射关系:git push origin master:main。 - 推送完成后,记得去GitHub页面右上角的分支下拉框里看一眼,确认你查看的是不是刚刚推送成功的那个分支。
说到底,Git和GitHub的协作像一套精密齿轮,每个环节都必须严丝合缝。远程地址的协议、认证方式、分支名称,甚至一个不起眼的初始化选项,都可能让整套流程“静默失败”——命令执行了,但结果不是你想要的。把这些细节理顺,推送代码就会变得像呼吸一样自然。
相关攻略
Git怎么创建GitHub仓库_Git关联GitHub远程仓库教程【入门】 想把本地代码推上GitHub,结果命令敲下去不是报错就是没反应?这事儿太常见了。别急,问题往往出在几个关键细节上。下面咱们就把从创建仓库到成功推送的完整链路,以及那些最容易“踩坑”的环节,掰开揉碎了讲清楚。 本地已有项目,怎
VSCode中生成规范commit的核心是“写得对且不被拒” 在VSCode里生成规范的Git提交信息,核心目标往往被误解。关键不在于“写得快”,而在于“写得对且不被拒”。手动敲入永远伴随着拼写错误、遗漏空行、scope大小写不规范等风险;依赖插件确实能绕过这些坑,但前提是必须选对插件、正确配对、并
根本原因是git lfs install仅配置本地钩子,未将已跟踪的大文件重写进LFS轨道,需先git lfs track指定文件类型,再git rm --cached后重新add以转换为LFS指针。 Git LFS初始化后push还是卡在大文件上 这事儿挺常见的:明明运行了 git lfs ins
如何规范团队的Git提交?Composer结合Husky实现代码提交前校验 先说一个核心判断:Composer 本身并不参与 Git 提交规范。你看到的所谓“Composer + Husky”组合,其实是一个常见的误区,本质上是混淆了前端与 PHP 生态的工具链。Husky 是 Node js 生态
Git Graph(mhutchie开发)最可靠:原生命令驱动,严格还原Git DAG拓扑 在Visual Studio Code里查看Git分支图,插件选择其实不少,但真正能让你“所见即所得”、分毫不差地还原Git内部有向无环图(DAG)结构的,首推Git Graph(作者:mhutchie)。
热门专题
热门推荐
Composer如何配置自定义的类加载路径_在 autoload 的 files 字段定义【进阶】 为什么加了 files 还是报 Call to undefined function 遇到这个问题,十有八九是源头就出了问题:入口文件压根没引入 vendor autoload php,或者引入的位置
VSCode 调试 Electron 主进程:告别“断点失效”,回归 Node js 本质 调试 Electron 主进程,核心思路其实很简单:把它当作一个特殊的 Node js 进程来对待。 关键在于,别再执着于 VSCode 里那个名为 “electron” 的调试类型,而是用 type: "n
git回退到指定版本的操作步骤【详解】 开门见山,先说结论:想把代码回退到某个特定版本,git reset --hard 无疑是速度最快、效果最彻底的方法。但请注意,这个“大招”有明确的适用范围:仅限于你的改动还没推送到远程仓库,或者你拥有强制覆盖远程分支的权限。一旦代码已经合入了团队共享的主干分支
Atom已停止维护,apm官方源失效,需改用社区镜像源(如https: apm atom io cn)或手动下载GitHub包安装;仍可用插件需满足不联网、不调API、无后端依赖等条件。 Atom编辑器在2022年底就正式告别了官方维护,这已经是公开的事实。但话说回来,它并没有从我们的硬盘里消失。
Composer脚本无法原生支持条件判断,因scripts字段仅将字符串交由系统shell执行,而CI中环境变量未导出、Windows语法不兼容、autoload未加载等问题导致if语句失败;应改用PHP回调函数显式检测环境变量并控制流程。 先说一个核心结论:Composer脚本本身不具备原生的条件





