Git基础

1、本地版本控制系统、集中式版本控制系统与分布式版本控制系统

       文档: Git - 关于版本控制
        1. 本地版本控制系统(Local Version Control System):
   本地版本控制系统是最简单的版本控制系统,它基于文件的复制和备份来记录和管理版本历史。开发人员在自己的计算机上维护一个本地代码库,可以通过手动复制和备份文件来跟踪和管理版本变化。这种系统只能由单个开发者在单个计算机上使用,无法实现多人协作和远程访问。

        2. 集中式版本控制系统(Centralized Version Control System,简称 CVCS)是一种版本管理系统,其中所有源代码和版本历史都存储在中央服务器上。开发者通过从中央服务器中拉取最新版本的代码,并将自己的更改推送到中央服务器来协作工作。每个开发者只能在一个中央代码库中工作,且需要定期与中央服务器进行通信以同步代码。

       3.  分布式版本控制系统(Distributed Version Control System,简称 DVCS)也是一种版本管理系统,不同于CVCS,每个开发者都拥有一个完整的代码副本,包括整个代码库和完整的版本历史记录。开发者可以在本地独立工作,无需频繁与中央服务器进行通信。DVCS 允许开发者在本地创建分支、进行更改、提交更改,并与其他开发者共享和合并这些更改。

        分布式版本控制系统每个开发者都有完整的代码库的拷贝,包括完整的历史记录。开发者可以在本地独立工作,并记录所有版本的历史。这意味着开发者可以在没有网络连接的情况下进行提交、分支、合并等操作,并具备本地备份能力。分布式版本控制系统支持多人协作和远程访问,开发者可以轻松地共享代码、合并更改,并在分布式环境中进行同步。缺点:分布式版本控制系统对于初学者来说可能复杂一些,需要努力理解和掌握分布式工作流程和协作方式。
常见的分布式版本控制系统有Git和Mercurial。

        简而言之,集中式版本控制系统依赖于中央服务器来存储和管理代码库,开发者需要通过与中央服务器的交互来进行协作。而分布式版本控制系统则将完整的代码库和版本历史记录分发到每个开发者的本地,开发者可以在本地独立工作,通过合并操作来进行代码的同步和协作。
 

2、分布式版本控制系统的提交与协作原理?

       “分布式版本控制系统中,每个开发者都可以在没有网络连接的情况下进行提交、分支、合并等操作”,为什么可以在没有网络连接的情况下进行提交、分支、合并等操作?开发者是在本地进行提交,那为什么还可以支持多人协作和远程访问? 

        在分布式版本控制系统(Distributed Version Control System,DVCS)中,每个开发者都可以在没有网络连接的情况下进行提交、分支、合并等操作的原因是每个开发者都拥有完整的代码库的副本。在一个分布式版本控制系统中,每个开发者都有一个完整的代码库复制品,包含了完整的历史记录和分支信息。这意味着每个开发者都可以在本地进行提交、分支、合并等操作,而无需依赖网络连接,无需与远程代码库进行通信。

        当网络连接恢复时,开发者可以将本地的提交、分支和合并操作同步到远程代码库中,并与其他开发者共享代码更改,因此支持多人协作和远程访问。分布式版本控制系统的这种权威性和灵活性使得开发者可以在独立的环境中进行工作,并在需要的时候才与其他开发者进行同步和协作。

3、为什么要版本控制?

对比文件在各个状态的区别

使文件回溯到某个指定的历史状态  

4、​​​​​​​Git文件的三种状态与GIt项目的三个section

1、Git文件的三种状态:已提交(commited)、已修改(modifiled)、和已暂存(staged) 

        已提交:表示数据已经安全地保存在本地数据库中。

        已修改:表示修改了文件,但还没保存到数据库中。

        已暂存:表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。

2、与此对应的是GIt项目的三个section:工作区、暂存区、Git目录。
Git基础_第1张图片

  • 工作区是对项目的某个版本独立提取出来的内容。这些从Gt仓库的本地压缩数据库中提取出来的文件,放在磁盘上供你使用或修改。修改后的文件放至暂存区。
  • 暂存区是一个文件,保存了下次将要提交的文件列表信息,一般在Gt仓库目录中。暂存区中“commit”才是真正的提交保存了。
  • ​​​​​​​Git仓库目录是Git用来保存项目的元数据和对象数据库的地方。这是GIt中最重要的部分,从其它计算机克隆仓库时,复制的就是这里的数据

    当从其他计算机克隆一个 Git 仓库时,复制的是整个 Git 仓库目录中的数据,而不仅仅是工作目录中的文件。这是因为 Git 采用了分布式版本控制系统的设计理念,每个克隆的仓库都是一个完整的副本,包含完整的历史记录、分支信息和元数据。该副本称为本地仓库。
    Git 的核心是一个版本控制数据库,数据库中存储了代码的完整历史和所有版本的元数据。当你克隆一个 Git 仓库时,实际上是将整个版本控制数据库完整地复制到本地计算机上。
    这样,当你在本地进行提交、分支、合并等操作时,Git 可以在本地仓库中处理这些操作,而不需要依赖网络连接和远程仓库。
    通过复制整个仓库目录中的数据,包括版本控制数据库和工作目录中的文件,Git 可以在本地完整地重现远程仓库的状态和历史,使得你可以在本地进行代码管理和版本控制的操作。同时,这也意味着你可以在没有网络连接的情况下进行提交、分支、合并等操作,只需要依赖本地仓库即可.

3、Git中的文件的状态变化周期:

  • Git基础_第2张图片

    请记住:对于一个刚刚clone到本地的repo,所有文件都是Unmodified状态.

    新创建文件:echo 'Hello World' > a.md
    就创建了一个名为a.md的文件
    可以使用git status命令查看文件状态:
    ​​​​​​​刚刚创建的文件,使用git add指令将文件提交到了暂存区,此时文件显示可以被提交了“commit”。
    Git基础_第3张图片
    此时再执行一个git commit就将暂存区的文件提交了。如果只输入git commit,则会跳转至一个交互的文件界面,可以在里面编辑一些提交信息。也可以在git commi后面加上一些参数,就不会发生跳转了。

    撤销提交申请:git reset命令

    创建文件:echo '文件内容' > 文件名
    查看文件状态:git status
    提交至缓存区:git add
    提交文件:git commit
    撤销提交申请:git reset
    ​​​​​​

4、分支的概念

这个可视化工具可以方便地学习分支变化:Learn Git Branching

分支是git最重要的的特性。
Gt的分支非常轻量,原因是它本质上仅仅是指向提交对象的可变指针。​​​​​​​
Git基础_第4张图片
使用git branch命令创建分支:git branch    分支名    (这会在当前所提交的对象上面创建一个指针)
例如:git branch   dev-1
Git基础_第5张图片所以在演示模型里此时看到,增加了一个“dev-1”的指针,指向了c2。main指针与dev-1指针同时指向了c2结点。
那么git又是怎么知道当前在哪一个分支上呢?也很简单,它有一个名为HEAD的特殊指针,指向当前所在的本地分支。(上面的演示中,main后面的*就是HEAD指针(头指针))
可以使用chekout命令,切换HEAD指针,移动到另一个分支上面。
例如:上面的演示中,HEAD分支在main上面,使用git chekout dev-1命令,可以是HEAD指针切换到dev-1上面。

可以使用git chekout -b创建并切换分支。
每次都要记得git commit
Git基础_第6张图片可以使用git merge命令合并分支。
例如:先把HEAD指针切换回main上,再将dev-1分支合并到main分支上:
 

git checkout main 
git merge dev-1

Git基础_第7张图片这时我们会发现并没有所谓的"合并”,而是main指针向前移动到dev-1指针的位置,这种叫作fast-forward merge.
如果顺着一个分支走下去能够到达另一个分支,那么Git在合并两者的时候,只会简单
的将指针向前推进(指针右移),因为这种情况下的合并操作没有需要解决的分歧一这
就叫做"快进(fast-forward)"。如果不能fast-forward merge,就会变成typical merge.(演示)
继续演示:
Git基础_第8张图片
所以,C1,C2……都是提交后更新?
Git基础_第9张图片
注:即使满足fast-forward条件,也可通过指定-no-ff参数转为typical merge.
如果合并过程中存在冲突,需要解决冲突,然后执行git merge continue继续完成合并。

远程分支:Git - 远程分支
Git基础_第10张图片

5、 Git的工作流程

注意与之前提到的GitHub Flow区分开。GitHub Flow是协作流。Git是本地操作流。

Git的工作流程如下:

1.在工作区中修改文件。

2.将你想要下次提交的更改选择性地暂存,这样只会将更改的部分添加到暂存区。

3.提交更新,找到暂存区的文件,将快照永久性存储到Gt目录。


1、确认本地Git已经安装好

检查git --version 是否出现git的版本即可。

2、做一些基本配置,这里主要配置全局user信息:​​​​​​​

git config -global user.name "双引号中写你的用户名"
git config -global user.email "双引号中写你的邮箱"

3、通过SSH访问GitHub:

终端输入ssh-keygen
然后输入文件名:ssh_Github_identification
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
这两行提示中,输入的密码将会成为为私钥设置的密码短语。
再执行: mv ssh_Github_identification ~/.ssh/ssh_Github_identification

将文件移至ssh目录下,方便使用。
下面的操作可以看教程:
新增 SSH 密钥到 GitHub 帐户 - GitHub 文档
 

此时是使用了 `ssh-keygen` 命令来生成 SSH 密钥对。这对密钥包括一个私钥和一个公钥,它们通常用于身份验证和安全通信。

1. 生成密钥对:`ssh-keygen` 命令生成了一个 RSA 密钥对,包括一个私钥和一个公钥。

2. 密钥保存位置:系统要求你指定一个保存密钥的文件位置。我将私钥和公钥保存在了一个名为 `ssh_Github_identification` 的文件中。
(通常,这两个密钥应该保存在默认的 `~/.ssh` 目录中,以确保 SSH 客户端能够找到它们。如果你选择将其保存在非默认位置,记得以后在使用 SSH 时要指定这个自定义路径。)

3. 密码短语:可以选择为私钥设置密码短语。密码短语是私钥的额外保护层,用于加强安全性。

4. 密钥指纹:SSH 生成了密钥的指纹,它是密钥的唯一标识符。它以 SHA256 格式显示,并附带一个随机艺术图像。指纹和随机艺术图像通常用于验证密钥的完整性。

​​​​​​​4、基本操作

1、使用Git clone命令克隆远程仓库到本地:
git clone github上仓库的链接

例如:Git基础_第11张图片Git基础_第12张图片

2、创建本地仓库
Git基础_第13张图片

使用mkdir创建一个本地仓库,使用git init命令初始化本地仓库成为一个git的一个管理仓库。
可以使用git status命令查看文件状态:

这表示当前分支和远程的分支保持一致。

​​​​​​​3、远程仓库交互

我们本地的代码都是通过git clone从远程拉取的,我们可以使用git remote命令查看远程仓库:
1、终端输入:git remote     会显示:origin

2、输入 git remote -v  显示当前Git仓库中配置的所有远程仓库的详细信息,包括远程仓库的名称和URL。

运行`git remote -v`命令会输出类似下面的信息:
origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

fetch是拉代码,push是推代码。

git fetch origin是拉取远程仓库代码(将远程仓库中的代码更新至本地仓库,如果没有显示,则代码两处的代码是一致的),
git pull origin:这个代码更经常使用,pull = fetch + merge
用于从名为"origin"的远程仓库拉取最新的代码更新到本地仓库并自动合并(merge)到当前分支。
3、添加其他远程仓库:git remote add
`git remote add`是一个Git命令,用于将一个远程仓库添加到当前的本地仓库中,并命名该远程仓库的别名。命令的语法如下:
git remote add <远程仓库别名> <远程仓库URL>

你可能感兴趣的:(科研,入学前实训课,git)