github 批量上传代码和文件

如果没有安装git 就去官网下载Git - Install for Windows

直接默认配置就可以


Git 初始化配置与首次推送代码仓库教程

目录

Git 初始化配置与首次推送代码仓库教程

步骤 0: 打开power shell用管理员运行

步骤 1: 设置全局 Git 用户名

步骤 2: 设置全局 Git 邮箱

步骤 3: 进入项目目录

步骤 4: 初始化 Git 仓库

步骤 5: 添加所有更改到暂存区

步骤 6: 提交暂存区的更改

步骤 7: 添加远程仓库地址(尝试)

步骤 8: 移除旧的远程仓库配置

步骤 9: 添加远程仓库地址(成功)

步骤 10: 验证远程仓库配置

步骤 11: 推送本地提交到远程仓库

错误排查

总结


本教程指导您完成 Git 的全局设置、仓库初始化、提交更改和首次推送到远程仓库的步骤。每个步骤包括命令和详细注解,帮助您理解操作含义。

步骤 0: 打开power shell用管理员运行
步骤 1: 设置全局 Git 用户名
git config --global user.name "your_username" 

注解:
这条命令设置 Git 的全局配置项 user.name,将其值设为 "your_username"。这指定了您在所有 Git 仓库中进行提交时使用的用户名。--global 表示此配置适用于当前用户的所有仓库。

步骤 2: 设置全局 Git 邮箱
git config --global user.email "[email protected]" 

注解:
这条命令设置 Git 的全局配置项 user.email,将其值设为 "[email protected]"。这指定了您在所有 Git 仓库中进行提交时使用的邮箱地址,同样通过 --global 使其全局生效。

步骤 3: 进入项目目录
cd D:\shawn\Desktop\Codes 

注解:
这条命令使用 cd(Change Directory)将当前工作目录切换到 D:\shawn\Desktop\Codes。这是您存放代码的项目文件夹。请根据您的实际路径调整此命令。

步骤 4: 初始化 Git 仓库
git init 

注解:
这条命令在当前目录(例如 D:\shawn\Desktop\Codes)初始化一个新的 Git 仓库。它创建了一个隐藏的 .git 文件夹,用于存储版本控制所需的所有信息(如提交历史、配置等)。如果输出显示 Reinitialized existing Git repository,表明该目录之前已经初始化过 Git 仓库,本次操作是重新初始化它。

步骤 5: 添加所有更改到暂存区
git add . 

注解:
这条命令将当前目录(例如 D:\shawn\Desktop\Codes)及其子目录中所有新的或修改过的文件添加到 Git 的暂存区(Staging Area)。. 代表当前目录。暂存区是准备进行下一次提交的文件快照。

步骤 6: 提交暂存区的更改
git commit -m "first time upload" 

注解:
这条命令将暂存区中的所有更改创建一个新的提交(Commit),并将这些更改永久记录在 Git 仓库的历史中。-m 参数后面跟着的字符串 "first time upload" 是本次提交的说明信息(Commit Message)。如果输出显示 nothing to commit, working tree clean,表明在工作目录中没有检测到新的、未跟踪的或修改过的文件需要提交(可能是因为之前已经提交过这些文件,或 git add . 之后没有新变化)。

步骤 7: 添加远程仓库地址(尝试)
git remote add origin https://github.com/your_username/testgit.git 

注解:
这条命令尝试将一个名为 origin 的远程仓库添加到本地 Git 仓库配置中。远程仓库的地址是 https://github.com/your_username/testgit.gitorigin 是远程仓库常用的默认名称。
错误处理: 如果输出显示 error: remote origin already exists.,表明名为 origin 的远程仓库配置已经存在于本地仓库中。需要先移除旧的配置。

步骤 8: 移除旧的远程仓库配置
git remote remove origin 

注解:
这条命令移除了本地 Git 仓库中名为 origin 的远程仓库配置。这是在尝试添加新的 origin 之前清理旧配置的必要步骤。

步骤 9: 添加远程仓库地址(成功)
git remote add origin https://github.com/your_username/testgit.git 

注解:
再次执行添加远程仓库的命令。这次成功地将地址为 https://github.com/your_username/testgit.git 的远程仓库添加到了本地配置中,并将其命名为 origin

步骤 10: 验证远程仓库配置
git remote -v 

注解:
这条命令列出所有配置好的远程仓库及其对应的 URL。输出通常显示:

  • origin https://github.com/your_username/testgit.git (fetch):名为 origin 的远程仓库的抓取(fetch)URL。
  • origin https://github.com/your_username/testgit.git (push):名为 origin 的远程仓库的推送(push)URL。
    这确认了远程仓库 origin 已正确配置。
步骤 11: 推送本地提交到远程仓库
git push -u origin main 

如果碰见这个报错

尝试

解决方法

注解:

  • git push:将本地仓库的提交推送到远程仓库。
  • origin:指定要推送到的远程仓库的名称(之前配置的)。
  • main:指定要推送的本地分支名称(这里假设您的本地分支叫 main)。
  • -u(或 --set-upstream):设置上游跟踪。这意味着以后在 main 分支上使用简单的 git pushgit pull 命令时,Git 会自动知道应该推送到或拉取自远程的 origin/main 分支。

输出解读:

  • 命令开始枚举、计数、压缩要推送的对象。
  • Writing objects: 100% 表示所有对象都已成功传输。
  • Total 5 (delta 1) 统计了传输的对象总数和差异大小。
  • remote: Resolving deltas: 100% 表示远程服务器成功处理了差异。
  • To https://github.com/your_username/testgit.git 显示推送的目标地址。
  • * [new branch] main -> main 表明本地 main 分支被成功推送到远程仓库,并在远程创建了一个新的 main 分支(因为远程原来可能没有这个分支)。
  • branch 'main' set up to track 'origin/main' 确认了 -u 选项的效果,本地 main 分支现在跟踪(track)远程的 origin/main 分支。

错误排查

git remote -v
显示当前仓库关联的远程仓库名称及其 URL(包括 fetchpush 地址),用于查看远程连接状态。

origin https://github.com/zhangsan/my-project.git (fetch) origin https://github.com/zhangsan/my-project.git (push) upstream https://github.com/original-project/my-project.git (fetch) upstream https://github.com/original-project/my-project.git (push) 

git config --global --list
列出当前用户的所有全局配置信息(如用户名、邮箱等),适用于查看或验证配置。

user.name=张三 [email protected] core.editor=code --wait alias.st=status http.proxy=http://proxy.example.com:8080 

总结

这一系列命令完成了:

  1. 设置全局 Git 用户信息(用户名和邮箱)。
  2. 在现有目录中初始化(或重新初始化)Git 仓库。
  3. 添加文件更改并提交到本地仓库历史。
  4. 配置指向远程仓库(例如 GitHub)的地址,命名为 origin
  5. 将本地 main 分支的提交首次推送到远程仓库,并建立跟踪关系。

完成这些步骤后,您的代码就成功上传到了远程仓库(如 GitHub 的 testgit 仓库)中。以后,您可以使用 git pushgit pull 简化操作。如果您在实际操作中遇到问题,请检查路径、权限或网络连接。

Read more

Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案

Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案 前言 在后疫情时代的协同办公浪潮中,视频会议已经从单一的垂直应用演变为鸿蒙(OpenHarmony)生态中“泛在协作”的核心基础设施。当你在鸿蒙平板上开启一场跨国技术评审,或者在鸿蒙车机上紧急连线公司晨会时,支撑这一切流畅运行的,是底层极其复杂的会议核心引擎。 meeting_place_core 是一套工业级的、专为多端同步设计的会议核心抽象包。它不负责 UI 渲染,而是专注于房间管理(Room Management)、成员状态流转、信令推送及媒体流的逻辑编排。 适配到鸿蒙平台后,结合鸿蒙强大的分布式能力,meeting_place_core 能让你的 App 轻松实现“手机开会,大屏投映,

By Ne0inhk
从海量时序数据到无人值守:数据库在新能源集控系统中的架构实践

从海量时序数据到无人值守:数据库在新能源集控系统中的架构实践

文章目录 * 引言 * 关于金仓数据库 * 金仓数据库在新能源行业的技术解读 * 1. 应对海量时序数据:分区存储与高效查询 * 2. 支撑高并发访问:读写分离与自治调优 * 3. 保障业务连续性:跨地域高可用与容灾 * 4. 实现平滑迁移:高度兼容与自动化工具 * 案例分析:金仓数据库赋能新能源智慧运维 * 案例一:中广核新能源生产运维系统——应对“整合、高并发、高可用”三大挑战 * 案例二:国家能源集团龙源电力——186个新能源场站集控系统国产化替代 * 案例三:国家电投集团甘肃新能源——“无人值守”风电场集控系统 * 结语 引言 谈到“双碳”与能源革命,风电,光伏这些新能源产业显然是当下最为炙手可热的风口,若想在该赛道跑得更远,更快,数字化和智能化转型并非可选,而是必备功课,要知道,从远程操控成千上万台风电机组,到及时分析大量的设备数据,直至把整个生产运维流程管理得井井有条,哪一步能离开稳定,高效且安全的数据“大后方”

By Ne0inhk
Flutter 组件 tw_queue 的适配 鸿蒙Harmony 实战 - 驾驭分布式高并发任务队列、实现鸿蒙端流式任务调度与生产级持久化断点续传方案

Flutter 组件 tw_queue 的适配 鸿蒙Harmony 实战 - 驾驭分布式高并发任务队列、实现鸿蒙端流式任务调度与生产级持久化断点续传方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 tw_queue 的适配 鸿蒙Harmony 实战 - 驾驭分布式高并发任务队列、实现鸿蒙端流式任务调度与生产级持久化断点续传方案 前言 在鸿蒙(OpenHarmony)生态的工业级应用或是大型协同办公软件中,我们时刻面临着“海量任务堆积”的挑战。例如:在 0307 批次的博文自动化生产线中,160 个文件、上百万字的博文生成、图片压缩以及云端同步任务,如果全部无脑地开启并发,会瞬间撑爆鸿蒙设备的内存句柄(OOM),同时也可能触发后端的限流封禁。 我们需要的是一个具备“理智”与“弹性”的交通管制系统。 tw_queue 是一套专为高性能、分布式任务调度设计的流水线工具。它不仅能控制并发数(Concurrency),更具备了任务持久化、失败自动重试、甚至是带权重的优先级调度能力。在鸿蒙适配实战中,tw_

By Ne0inhk
Flutter 组件 ubuntu_service 适配鸿蒙 HarmonyOS 实战:底层系统服务治理,构建鸿蒙 Linux 子系统与守护进程交互架构

Flutter 组件 ubuntu_service 适配鸿蒙 HarmonyOS 实战:底层系统服务治理,构建鸿蒙 Linux 子系统与守护进程交互架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 ubuntu_service 适配鸿蒙 HarmonyOS 实战:底层系统服务治理,构建鸿蒙 Linux 子系统与守护进程交互架构 前言 在鸿蒙(OpenHarmony)生态迈向工业互联、智能车载及深度客制化终端的背景下,如何实现 Flutter 应用对底层 Linux 服务(如 Systemd/DBus)的受控访问、在端侧治理长驻守护进程,已成为提升应用系统级集成能力的“技术门槛”。在鸿蒙设备这类强调内核级安全防护与微内核分布式调度的环境下,如果应用仅能实现表层 UI 的交互,而无法感知、重启或监控底层硬件驱动相关的后台服务,就无法在大屏中控、工业看板或服务器管理设备中胜任“控制塔”的角色。 我们需要一种能够穿透沙箱壁垒、支持 DBus 通信协议且具备高可靠服务状态感知能力的系统治理方案。 ubuntu_service 为

By Ne0inhk