当前位置: 首页 > news >正文

Github的仓库使用方法的小白教程

一、从仓库中clone到本地文件:

1. 先在Github中创建一个存储库,如下图所示,点击右上角的New,

之后就会进入到这个界面 

 1.没有添加README.md文件的情况:

因为我在创建的时候没有添加README.md文件,所以它展示的是默认页面,因为我的仓库什么都没有.它就会给我展示一些简单的指令(如下面的界面)

// 这里大家可能会疑惑,这个仓库地址是干嘛用的?别着急,在后面会讲到.

这个存储库你就把它当成文件夹就行了,里面存放的是你自己需要放的任何东西.因为之后可能我们还会有更多的存储库,考虑到管理是否方便这个问题 , 所以我们可以在资源管理器中去创建一个文件夹(我命名为GitProject),方便后续管理我们的存储库 :

之后打开Bash(就不讲解这个的下载了,某站上随便找找就有):

点击后进入下面这个页面:

再进入资源管理器中,进行下面的操作

 再回到Bash中,输入一下命令(先输入cd 再把位置粘贴到上面去)

红色部分就是粘贴,只要你复制了内容,它就会显示黑色 而不是灰色(如上面图片中这个状态,这个状态是点不了的)

 

这里如果你没有成功进入到这个目录下,你把"命令: cd E: \GitProjects"换成"cd E:/GitProjects"(因为你可以观察到在Bash中,它这个用的不是'\'而是'/' ,所以有时候你输入'\' 它就会不成功)

可以看到,我们进入到了GitProjects这个目录了 ,接下来执行下面图片中的命令:

 git clone 后面的地址就是我们存储库的地址,也就是刚刚 上面的SSH后面的地址 直接粘贴到git clone 的后面即可(记得空格 别把每个单词都连在一起了)    接下来 ! 回车!!  

"如果是第一次使用SSH,需要配置SSH(配置一次就可以了),配置方法我放在最底部了,大家也可以自己去问gpt其他什么的AI也可以"

就会出现上面的页面.

我们可以去文件夹中看看,是否有Test这个文件出现在GitProjects这个目录下面:

进入到Test文件夹中,会发现一个名为.git的文件:

这个文件夹就是本地 Git 仓库(是本地Git仓库,不是Github存储库.二者是不一样的东西,在常见命令的解释中的 第2. 和3. 有解释)的“核心”,用来保存版本控制相关的所有信息(比如提交记录、分支、配置、仓库的地址等)。因为Test是我们直接从Github仓库中clone下来的,所以它自动的生成了.git文件     git文件会自动生成的情况: 1. 输入指令git init 命令 2. 将Git存储库clone到本地文件中.

你可以尝试在Bash中去输入:

 因为我们此时位于GitProjects这个目录,Test是在该目录下,所以我可以直接cd Test 进入该目录 在执行 git remote -v命令,该命令是 查看仓库的地址的一个命令. 这里有两个相同的地址,第一个是指从这个地址中拉取东西到本地文件中(Test中).  第二个地址是指,我以后在本地文件(Test)上传的内容到这个地址(仓库)中去.

// 为什么要先 cd Test . 假如你不进入到这个Test文件夹中,那么它识别的是在目录GitProjects下的内容,GitProjects下的内容是三个文件夹

 它不能进一步的进入到这些文件夹中,它只能识别自己目录下的内容,而在这个目录下并没有.git文件,所以Git命令识别不了这个文件是不是仓库,就无法正确执行命令. 只有进入到Test(有.git文件)中,才能正确的执行git的命令.  我们的命令前面都有git这个前缀,这就是git命令的标志.

之后在资源管理器中或者在VS中进入到Test文件中,新建文件夹还是新建文件都可以,看自己需要什么,资源管理器中只能新建文件夹,在VS中可以新建文件夹和文件. (如果你是想在VS中去新建,你得先打开GitProject这个文件)

这两个创建方式本质上没有区别,新建的文件都会被Git识别,只要在仓库(我们这里是Test)目录下即可. // Git只要看到有新文件,无论你怎么新建都一样,后续git add . 就能追踪( git add . )

我这里就在Test中建立一个.md文件,在左侧 README.md 的右侧有一个U的标志,这是因为我们还没有上传到Github的仓库,'U'的意思的是未跟踪的状态. 编辑完后记得 ctrl + s 保存.

之后打开Bash ,分别执行下面三条命令:

git add .

git commit -m"...更新的内容..."

git push origin main

 关于 git push origin main 这段代码,需要大家简单了解一下什么意思:

0.  git push origin main这个命令的作用就是: 将我以后每次推送的内容 ,这个内容送到的地方 ,把这个地方设置成origin的地址,分支设为名叫mian的这个分支  . 简而言之就是: 显式推送到名为origin的远程仓库的指定分支(main分支)

1.git push :这个没什么好解释的...上面的这张" 白图黑字 "也有解释.

2.origin  : origin 是 Git 给远程仓库起的一个默认别名(origin就是你在github上建的存储库的小名,所以你在Bash中的Test目录下,对origin的操作就是对Test这个仓库的操作,当然假如你在Github上有其他的存储库,假设叫A,同样的,你在Bash中进入A的目录下,对origin的操作也是对A的操作,这里可能有的人会有疑问?那它们的小名都叫origin,怎么分清它们呢?这就看你在Bash中进入的位置了,你进的是A的目录下,对origin的操作就是对A的操作,同理你进入Test的目录下,对origin进行的操作就是对Test的操作),一般你用 git clone 或 git remote add 的时候,Git 自动帮你把你的仓库地址叫做 origin。除非你自己在Bash中手动的更改了远程仓库的别名(执行了 git remote rename origin github        // 这里的命令就是将origin这个别名更改为github). 

3.关于什么是分支,为什么需要分支?我把解析放在底部了(其实大家暂时可以不需要去了解,不影响你上传到仓库).

 执行完上面的三条命令之后,你可以去Github的Test存储库查看,是否上传成功:

 很明显,我们成功了!!! 这是我们第一次在Bash中的Test这个目录中上传内容,由于我们在第一次上传的时候执行了 git push origin main 这个代码,它已经帮我们设置好了默认的情况 ,之后只要是在Test这个你已经上传过一次内容的目录下,去上传其他的更改的内容的时候, 执行以下的命令就可以了:

git add .
git commit -m"......"
git push

第三行的代码 : git push(隐式调用) 就相当于 git push origin main(显示调用),这两者是等价的. 

如果你手动的更改了仓库的别名,那么很遗憾的告诉你: 改了别名,以后每次上传都要用新的别名,比如 git push myrepo main

 可以对比第一次的那三行代码看看 , 仅仅是最后一行代码稍作变化 其他的两行代码都一样 . 

2.最开始在Github中创建存储库的时候选择了添加RAEDME.md

 那么你看到的页面将会是下面这种页面:

多了一个README.md文件,但是少了最开始的部分的代码的介绍.  不过这些不重要 ,重要的是我们得找到SSH连接方式的仓库地址.因为我们是打算用这个方式来联系本地文件和Github存储库的.

添不添加README.md文件,仅仅就这点区别而已. 只是需要我们点击Code 去找一下(SSH)仓库地址而已,其余的操作都一样,不要忘记 如果从来没有配置过SSH密匙的话 ,要记得配置一下(方法我发在底部了)

二、本地文件已经存在,想要把文件里的内容上传到Github的存储库上去:

1. 想要在Github上新建一个存储库,再把本地文件里的东西传上去

1.1.在Github网站上新建仓库(repository)

        登录Github,点击右上角“New repository”

        填写仓库名等信息,点击“Create repository”

1.2 将本地文件夹与远程仓库关联

        cd 本地项目文件夹(就是有内容的那个文件夹)

        git init

        git add .

        git commit -m "首次提交"

        git remote add origin https://github.com/你的用户名/仓库名.git

        git push -u origin main ( 或 master 不太建议master),视你的默认分支

2. 把本地文件上的内容传到Github上的一个存储库中(已经存在的存储库)

(1) 目标仓库是空的,没有任何内容:

操作流程:

假设你已经在Github上有了目标仓库,只需将本地项目与这个仓库关联并上传。

在Bash中 cd 进入你的本地项目文件夹

# 1. 若未将本地文件初始化过(都没初始化过,更不用说配置远程仓库的地址了)git init                  //这一步是将本地文件初始化

git add .

git commit -m "首次提交"

git remote add origin https://github.com/你的用户名/仓库名.git  //添加远程仓库的地址

git push -u origin main

#2. 若已经将本地文件初始化过了,曾经用这个本地仓库已经关联过Github上的其他仓库之后,想要换不同的目标仓库,将本地仓库中的内容传到另一个目标仓库当中:

你可以 cd 先进入到 本地文件的目录当中:

// 查看当前关联的远程仓库的信息,确认是不是与这个仓库取消关联

输入命令: git remote -v 

(你会看到类似 origin https://github.com/xxx/原仓库名.git)

// 更改远程仓库地址为新目标仓库

输入命令: git remote set-url origin https://github.com/你的用户名/新仓库名.git  

//同步到远程仓库

git push -u origin main

#3. 若将本地文件初始化过了,已经把它作为了仓库来准备了,但是并没有为它配置过仓库的地址:

git add .

git commit -m "首次提交"

git remote add origin https://github.com/你的用户名/仓库名.git  //添加远程仓库的地址

git push -u origin main

//这与第一点没啥区别,就是少了一步初始化过程

(2) 目标仓库有内容:

解决步骤

1. 首先尝试 push

git push -u origin master # 或 main

如果成功了,说明没冲突,万事大吉!

2. 如果失败(提示非快进 push 被拒绝)怎么办?

A. 先拉取远程分支

(假设你的分支叫 main,如果叫 master,就相应替换)

git pull --rebase origin main

这一步会把远程的新提交(比如README.md)拉下来,和你本地合并(用rebase,历史更直观)。

B. 解决可能的冲突

如果本地和远程有同名文件(比如你本地也有README.md),Git会提示你解决冲突。

打开冲突的文件,根据注释,保留或合并内容。

冲突解决后,执行:

git add .   

git rebase --continue  或者 git commit

C. 再次 push

git push -u origin main

B. 的解决冲突详细解释:(如何解决冲突)

这里的“解决冲突”,意思是:本地和远程有同名文件,但内容不同,Git 不知道该保留哪一份,于是让你自己做决定。

B1. 冲突发生时会发生什么?

        1.1 Git 会暂停合并,把冲突的文件(比如 README.md)用特殊格式标记出来。

        1.2 你用文本编辑器打开冲突文件,就会看到像下面这样的内容:


<<<<<<< HEAD

这是你本地(当前)文件的内容

=======

这是远程仓库(pull下来)的内容

>>>>>>> origin/master


B2. 你要怎么做?

        2.1你需要手动编辑这个文件,删掉这些 Git 的标记(<<<<<<<, =======, >>>>>>>),然后把你想要保留的内容整理出来。

        2.2比如你决定全部保留,可以这样:


这是你本地(当前)文件的内容

这是远程仓库(pull下来)的内容


        2.3或者你只保留一份内容,按你的需要来。

B3. 解决流程举例:

        3.1 打开冲突文件(如 README.md)

        3.2找到冲突区域,像这样:


<<<<<<< HEAD

本地内容

=======

远程内容

>>>>>>> origin/master


        3.3删除冲突标记,只留下你想要的内容

        3.4保存文件(保存更改的内容)

//同样的针对于git push -u origin mian 这个命令,只有首次将内容推到远程仓库中的时候是这样子的指令,之后,这一个指令完全可以直接改为 git push (这种隐式的去执行),二者是等价的

小结

  • 远程仓库空的:直接 push 没问题。

  • 远程仓库有内容git pull --rebase origin master,合并好冲突,再 push。

  • 一句话记住:

    新仓库如果不是空的,先pull再push,冲突就解决了!

三、一些常见的命令的解释:
 

1. git add . 这行代码什么意思?

git add .

这条命令的作用是:把当前目录下的所有文件和文件夹添加到Git的暂存区(stage/index)。

意思是:

“告诉Git,我准备好把这些改动提交了。”

其中 .(点)代表“当前目录下的所有文件和子目录”。

举例

假如你新建了几个文件、修改了某些内容,运行 git add .,这些变动都会被Git记录下来,准备提交。 

 2. git commit -m" "

git commit -m "首次提交" 这行代码什么意思?

git commit -m "首次提交"

作用:把已经 add(暂存区)里的所有文件保存成一个“快照”(commit)。

-m 后面跟的是提交说明,比如“首次提交”。

简单理解:

这一步是正式把你的更改保存到"本地Git仓库"的历史里。

// "本地Git仓库" "Github上的存储库"不是同一个东西

举例

刚才你用 git add . 选好了所有要保存的内容,这一步就是“拍板”,写个说明,Git正式保存快照。

 3.git push

git push 的作用是:

把你本地Git仓库中的提交(commit)上传到远程仓库(比如Github)。

详细点说:

本地操作(add、commit)

你的更改只在本地(本地的Git仓库中),远程仓库(Github)啥也不知道。

git push

这一步相当于“把本地保存好的所有提交,送到远程仓库”,让远程仓库和你本地仓库同步。

你和其他人就可以在Github网页上看到你最新的提交和更改了。

一句话总结:

git push = “把本地仓库(也可以叫做本地Git仓库)里的最新内容提交到远程仓库(Github等)”。

4.git log

 

用法详解

4.1 git log

显示所有的提交记录(commit history)。

包括每次提交的作者、时间、提交说明、commit ID等。

常用变体:

显示简要历史:

4.2 git log --oneline

每个提交只显示一行,简洁明了。

只看最近3条历史:

4.3 git log -3

可视化分支结构(树形):

git log --graph --oneline --all

例子:

$ git log --oneline

e4c63b7 首次提交

3b28a42 添加了readme文件

de4b7e2 修复bug

4.4 补充说明:

这些记录只代表你本地的Git仓库历史。

只有 push 到远程后,Github上才会看到这些提交。

如果你想看某个文件的历史,也可以用:

git log 文件名

5. git init 

初始化本地文件,让Git开始管理这个目录

1

执行完后,本地文件的目录中就会出现一个.git 文件,在这之后,Git就知道这个文件是一个仓库了,在Bash中就可以在这个文件的目录中执行命令了.

6.git remote add origin https://......  远程仓库的地址(就是SSH后面那串东西)

举例: git remote add origin git@github.com:zhong-shengyou/Test.git

        这串命令就是 设置仓库的地址

一般情况下都是搭配 git init 一起使用.   使本地文件与Github远程仓库关联上的操作.

你别把 origin  给改成其他名称了 这里的origin 就是我在第一点中提到的别名. 没事改这玩意干啥!!!!!!!!!!!!!!!!!!!!!!!!!!

一定要先执行 git init 再执行 git remote origin <仓库地址> 

如果 你先执行 git remote origin <仓库地址> 会不成功,因为你的本地文件目录中并没有.git 文件,Git 不知道你这个本地文件是不是仓库,所以在Bash中的你的这个本地文件的目录下,执行相关的git命令是不成功的. 必须先执行 git init 把本地文件初始化成一个仓库(使本地文件中生成 .git文件) , 但是要知道,你只是把本地文件初始化成了一个仓库,还并没有与Git远程仓库(存储库)建立联系,所以还需要执行 git remote add origin <仓库地址> 这一步执行完后,就正式的将本地仓库(也可叫做本地Git仓库)和Github上的远程仓库(存储库)关联上了(我的个人建议是,如果你没有对本地文件进行初始化,那么就叫它本地文件,进行初始化后,就叫它本地Git仓库 或者 本地仓库).

7.关于 git init 和 git remote add origin <仓库地址>的顺序上的一些问题

3. 命令顺序问题:可以先 git init,马上 git remote add 吗?

完全可以!

在你执行了git init之后,马上就可以执行git remote add origin <仓库地址>,不需要等到add和commit后再加远程仓库。

这样做也是完全合理的,不会有任何坏处。

什么时候需要先加远程?什么时候可以后加?

先加远程:如果你一开始就知道要推送到远程仓库,可以先加远程,再慢慢add和commit。

后加远程:如果你只是想本地管理一段时间,等到需要同步到远程再加也可以。

常见顺序比较

一般常见两种写法:

A.先提交后添加 remote:

git init

git add .

git commit -m "首次提交"

git remote add origin <仓库地址>

git push -u origin master

B. 先加 remote 后 commit:

git init

git remote add origin <仓库地址>

git add .

git commit -m "首次提交"

git push -u origin master

**这两种都没问题!**Git并不强制顺序,只要你在push之前把remote加好就行。

建议:

**习惯用法还是先把本地仓库内容整理好(add和commit),再加远程。**这样逻辑比较清晰,和很多官方文档的习惯一致。

但是如果你觉得自己记得住,不怕麻烦,提前加remote完全没问题,有时甚至更方便,尤其是后续直接clone或pull的时候。

 

 四、底部:

底部一: SSH配置方法:

一、生成 SSH 密钥对

1. 打开终端(命令行)
  • Windows:可以用 Git Bash 或者 PowerShell

  • macOS / Linux:打开终端

2. 运行生成命令

ssh-keygen -t ed25519 -C "your_email@example.com"

  • 如果你的系统不支持 ed25519,可以用 rsa

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

这里的 your_email@example.com 替换成你注册 GitHub 的邮箱。

3. 按提示操作
  • 它会提示你保存密钥的位置(默认就是 ~/.ssh/id_ed25519),直接回车即可。

  • 你可以设置一个密码短语(passphrase),也可以直接回车不设。


二、添加 SSH 公钥到 GitHub

1. 复制公钥内容

运行以下命令,把公钥复制出来:

cat ~/.ssh/id_ed25519.pub

(如果你用的是rsa,就改成id_rsa.pub

复制终端显示的全部内容。

2. 登录 GitHub,进入:

Settings > SSH and GPG keys > 点击 New SSH key

  • 填写 Title(随便起个名字)

  • 粘贴刚才复制的公钥内容

  • 点击 Add SSH key


三、测试连接

运行命令测试:

ssh -T git@github.com

如果是第一次连接,会提示是否确认,输入 yes

然后会显示类似:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

说明配置成功。


四、配置 Git 使用 SSH

如果之前你是用 HTTPS 方式克隆的仓库,可以切换成 SSH:

git remote set-url origin git@github.com:username/repository.git

底部二:为什么存在分支,分支是什么?

 

1. 多人协作,为什么用分支?

  • 主分支(如 main)通常是“稳定版”或者“发布版”,主要负责人(你)在这上面做主要修改和维护。

  • 其他开发者(B、C)通常在自己的“功能分支”上工作,避免直接修改 main,减少冲突。


2. 你说的场景举例

  • 你是A,主要负责人,在 main 分支工作,做了6次修改

  • 你可以通过命令查看每次提交历史和具体内容:

    git log

    这能列出所有提交记录,每次修改对应一个提交(commit),里面有时间、作者、提交说明

  • 如果想看某次修改的代码,可以用:

    git checkout <commit-id>

    或者在图形化工具里查看版本差异


3. B和C的分支管理

  • B、C不直接操作 main 分支,分别新建自己的分支,如:

    git checkout -b feature-B git checkout -b feature-C

  • 他们在各自分支自由开发,提交历史也独立

  • 这样不会和你(main)冲突,也不会和对方冲突,方便定位是谁做了哪些改动


4. 合并代码(Merge)

  • B、C开发完成后,发起合并请求(Pull Request),请求把自己的分支合并到 main

  • 你作为负责人,审查代码后合并,保证代码质量和功能正确

  • 这样整个流程清晰,责任明确,冲突可控


5. 其实大家都在一个分支上的情况

  • 是可以的,但容易出现以下问题:

    • 频繁冲突:多个人同时改同一文件,容易冲突难解决

    • 历史混乱:提交历史交错,难以追踪是谁做了什么改动

    • 版本不清晰:难区分哪个版本是稳定版,哪个是开发版


6. 版本管理的好处

  • 每次提交都是版本快照,可以随时回退

  • 通过分支区分不同功能、不同人员工作,清晰明了

  • 方便协作,避免相互影响

http://www.lryc.cn/news/571900.html

相关文章:

  • 分布式顺序数据发生器
  • 国产服务器【银河麒麟v10】【CPU鲲鹏920】部署Nacos
  • 嵌入式自学第四十二天
  • 介绍下分布式ID的技术实现及应用场景
  • 轻量化分布式AGI架构:基于区块链构建终端神经元节点的互联网智脑
  • 【AI Study】第三天,NumPy(3)- 基础知识
  • 英一真题阅读单词笔记 13年
  • 从0开始学习R语言--Day27--空间自相关
  • 爬虫技术:数据挖掘的深度探索与实践应用
  • 榕壹云外卖跑腿系统:基于Spring Boot的开源生活服务平台技术解析
  • python打卡day54@浙大疏锦行
  • 如何高效实现公司文件管理
  • 精通现代开发栈:Python、Git与Docker实战指南
  • 警惕GO的重复初始化
  • RabbitMQ七种工作模式
  • Redission实现的分布式锁的可重入性
  • Web安全性测试--超详细用例CASE整理总结
  • leetcode-3405 统计恰好有k个相等相邻数组的个数
  • C2远控篇CC++InlineHook挂钩动态API调用突破内存加密导入表检测
  • JSX 详解:React 的核心语法
  • Meta V-JEPA 2:革命性的视频联合的世界模型
  • OpenStack体验
  • 深入理解 MySQL 事务:保障数据操作的原子性与一致性
  • MySQL 库操作和表操作
  • 【51单片机】8. 矩阵LED显示自定义图案、动画
  • Mac m1 通过docker镜像安装kafka
  • 【GateWay】和权限验证
  • RKNN开发环境搭建3-RKNN Model Zoo 板载部署以Whisper为例
  • 【AI作画】用comfy ui生成漫画风图画
  • spring-webmvc @InitBinder 典型用法