前端学习13 git使用
1.git 概述
Git 是一个分布式版本控制系统，用于跟踪文件的变化，尤其是程序代码的变化。它由 Linus Torvalds（Linux 操作系统的创建者）于 2005 年开发。Git 允许开发者在本地创建代码仓库，进行文件修改、提交等操作，直到准备好与远程仓库同步。Git 提供强大的分支管理功能，可以在不干扰主分支的情况下开发新功能或修复 bug。
Git 与其他版本控制系统的区别
集中式版本控制系统（如 SVN）：所有的代码版本保存在一个中央服务器中。每次操作都需要连接到服务器。
分布式版本控制系统（如 Git）：每个开发者的工作站都有完整的代码历史记录，可以脱离服务器工作，直到需要同步时才连接(通过push pull操作)。
2.Git的核心概念
Git本地有四个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)、git仓库(Remote Directory)。文件在这四个区域之间的转换关系如下：
Workspace：工作区，就是你平时存放项目代码的地方
Index / Stage： 暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息
Repository：仓库区（或版本库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本
Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换
git的工作流程一般是这样的：
１、在工作目录中添加、修改文件；
２、将需要进行版本管理的文件放入暂存区域；
３、将暂存区域的文件提交到git仓库。
因此，git管理的文件有三种状态：已修改（modified）,已暂存（staged）,已提交(committed)
3.文件状态
Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged。
Unmodify : 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified。如果使用git rm移出版本库, 则成为Untracked文件。
Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过,返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改。
Staged: 暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存,文件状态为Modified。
新建文件--->Untracked
使用add命令将新建的文件加入到暂存区--->Staged
使用commit命令将暂存区的文件提交到本地仓库--->Unmodified
如果对Unmodified状态的文件进行修改---> modified
如果对Unmodified状态的文件进行remove操作--->Untracked
4.常见命令
1、新建代码库
//在当前目录新建一个Git代码库
git init
//新建一个目录，将其初始化为Git代码库
git init [project-name]
//下载一个项目和它的整个代码历史
git clone [url]
2、查看文件状态
//查看指定文件状态
git status [filename]
//查看所有文件状态
git status
3、工作区<-->暂存区
//添加指定文件到暂存区
git add [file1] [file2] ...
//添加指定目录到暂存区，包括子目录
git add [dir]
//添加当前目录的所有文件到暂存区
git add .
//当我们需要删除暂存区或分支上的文件, 同时工作区也不需要这个文件了, 可以使用（⚠️）
git rm file_path
//当我们需要删除暂存区或分支上的文件, 但本地又需要使用, 这个时候直接push那边这个文件就没有，如果push之前重新add那么还是会有。
git rm --cached file_path
//直接加文件名 从暂存区将文件恢复到工作区，如果工作区已经有该文件，则会选择覆盖
//加了【分支名】 +文件名 则表示从分支名为所写的分支名中拉取文件 并覆盖工作区里的文件
git checkout
4、工作区<-->资源库（版本库）
//将暂存区-->资源库（版本库）
git commit -m '该次提交说明'
//如果出现:将不必要的文件commit 或者 上次提交觉得是错的 或者 不想改变暂存区内容，只是想调整提交的信息
//移除不必要的添加到暂存区的文件
git reset HEAD 文件名
//去掉上一次的提交（会直接变成add之前状态）
git reset HEAD^
//去掉上一次的提交（变成add之后，commit之前状态）
git reset --soft HEAD^
5.分支
在平时的开发中，我们通常会在 Git上建立多个分支，以方便代码的管理与维护，比如【master-dev】开发模型，这种开发模型就是 master存放已完成的代码，而 dev是平常用来开发的分支，开发完成后再将 dev分支合并到 master分支，当然有的大型项目还会有 bugfix这种专门修bug的分支或者有 product等等其他分支。
5.1合并（git merge）
整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照以及二者最近的共同祖先进行三方合并，合并的结果是生成一个新的快照（并提交）。
git switch master
git merge experiment
//没有冲突时不需要下方的命令。有冲突时，就修改冲突文件，再add然后commit该文件，如下：
git add readme.txt
git commit -m "conflict fixed"
合并是一个非常直观和简单的操作，特别适用于多人协作开发的场景。它保留了分支的历史记录，显示了每个分支的贡献。
5.2 变基（git rebase）
实，还有一种方法：你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基（rebase）。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。
git rebase master experiment
//或者
git switch experiment
git rebase master
变基的主要好处是，它可以保持一个干净的提交历史记录。相比之下，合并会产生很多合并提交，使得提交历史变得混乱。变基通常在工作完成后的合并之前使用，以便保持提交历史的整洁和易于理解。
5.3 如何选择合并或变基
通常情况下，合并是更安全和推荐的方法。它可以处理更复杂的合并操作，包括有冲突的情况。合并可以保留每个分支的完整历史记录，使得问题定位和回滚更加容易。
然而，当我们需要保持提交历史记录的整洁和易于理解时，变基是更合适的选择。它可以将一个干净的提交历史记录应用到主分支中，使得整个项目的历史记录更易于理解和追踪。
#前端学习#