企业网站用什么做,网站设置的参数,望野博物馆馆长,网站用户账号ip查询总言 主要内容#xff1a;主要介绍Git中常用的指令。 PS#xff1a;多人协作与企业开发模型使用#xff0c;此部分内容不作博文总结。 文章目录 总言1、初识Git1.1、版本控制器1.2、git安装 2、基本操作2.1、Git本地仓库2.1.1、创建Git本地仓库主要介绍Git中常用的指令。 PS多人协作与企业开发模型使用此部分内容不作博文总结。 文章目录 总言1、初识Git1.1、版本控制器1.2、git安装 2、基本操作2.1、Git本地仓库2.1.1、创建Git本地仓库git init2.1.2、配置Git本地仓库git config 2.3、认识工作区、暂存区、版本库2.4、文件修改新增、修改、删除2.4.1、添加文件演示 git add、git commit、git log、git cat-file2.4.2、修改文件演示 git status、git diff2.4.3、版本回退演示 git reset、git reflog2.4.4、撤销修改2.4.4.1、基础说明2.4.4.2、撤销情况一尚未 add 的代码只存在工作区2.4.4.3、撤销情况二已经 add 但没有 commit 的代码存在于工作区、暂存区2.4.4.4、撤销情况三已经 add 并且commit 的代码存在于工作区、暂存区、版本库 2.4.5、删除文件 3、分支管理3.1、理解分支git branch3.2、分支基本操作3.2.1、创建分支git branch new-branch3.2.2、切换分支git checkout/git switch new-branch 、git checkout -b3.2.3、合并分支与合并冲突git merge、 git log --graph3.2.4、删除分支git branch -d3.2.5、选择分支合并模式- - no - ff 3.3、分支管理策略3.3.1、分支策略3.3.2、bug分支git stash、git stash list、git stash pop等3.3.2.1、准备工作与如何使用bug分支3.3.2.2、master分支bug修复后后续dev操作 4、远程操作4.1、分布式版本控制系统4.2、远程仓库4.2.1、新建远程仓库4.2.2、克隆远程仓库git clone4.2.3、查看远程库信息git remote4.2.4、向远程仓库推送git push4.2.5、拉取远程仓库git pull4.2.6、配置Git忽略特殊文件.gitignore 5、标签管理5.1、理解标签5.2、标签相关操作5.2.1、创建与查看标签git tag、git show5.2.2、推送标签到远端git push5.2.3、删除标签git tag -d、git push --delete Fin、共勉。 1、初识Git
1.1、版本控制器 1、理解版本控制器 所谓的版本控制器就是能让你了解到一个文件的历史以及它的发展过程的系统。通俗的讲就是一个可以记录⼯程的每一次改动和版本迭代的一个管理系统同时也⽅便多⼈协同作业。 2、Git 目前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的⽂件例如 doc、excel、dwg、dgn、rvt等等。而对于开发⼈员来说Git 最重要的就是可以帮助我们管理软件开发项目中的源代码文件。
1.2、git安装 1、基础说明 Git 是开放源代码的代码托管⼯具最早是在Linux下开发的。开始也只能应应用Linux平台后面慢慢的被移植到windows下现在Git可以在Linux、Unix、Mac和Windows这几大平台上正常运运行。 2、安装操作 略。这里可根据平台需求自行搜索了解。
2、基本操作
2.1、Git本地仓库
2.1.1、创建Git本地仓库git init 1、Git本地仓库 说明仓库是进行版本控制的⼀个文件目录。我们要想对文件进行版本控制就需要创建一个仓库出来。在Git中你可以有一个或多个本地仓库repository每个仓库都包含项目的所有文件和版本历史。 2、如何创建本地仓库 git init在指定目录中初始化一个新的 Git 仓库。当运行该命令时Git 会在当前目录下创建一个名为 .git 的子目录这个子目录包含了仓库的所有必要元数据如对象数据库、引用、钩子hooks、配置信息等。 3、 .git 目录 .git 目录是 Git 仓库的核心组成部分它包含了仓库的所有元数据和对象数据库通常是一个隐藏目录可供 Git 用于跟踪管理仓库。一般情况下不要手动修改这个目录里的文件改乱极有可能会破坏 Git 仓库。 注意事项 1、如果 .git 目录已经存在即该目录已经是一个 Git 仓库再次运行 git init 命令将不会有任何效果。 2、可以使用 git init --bare 命令创建一个裸仓库bare repository。裸仓库不包含工作目录通常用于在服务器上存储共享的 Git 仓库。 3、在初始化 Git 仓库之前确保你的目录是干净的不包含与项目无关的文件或目录。这些文件或目录将不会被 Git 跟踪但它们的存在可能会干扰你的工作。
2.1.2、配置Git本地仓库git config 1、添加两个配置项name、email 当安装 Git 后首先要做的事情是设置你的 用户名称 和 e-mail 地址。
// 新增配置
git config [--global] user.name Your Name
git config [--global] user.email emailexample.com--global 是⼀个可选项。由于一个本地服务器可以存在多个本地仓库因此若使用该选项则表示这台机器上所有的 Git 仓库都会使用当前设置的配置。 如果需要在不同仓库中使用不同的 name 或 e-mail 可以不加 --global 选项。PS执行这些命令时必须要在仓库里 相关演示如下 2、查看配置和删除配置的相关指令 -l 是 --list 的缩写表示列出所有设置。这个命令用于列出当前 Git 仓库的所有配置设置包括全局设置和本地仓库设置。
git config -l --unset 选项表示要删除一个设置。user.name 和 user.email 是要删除的配置项可根据需求修改为其它待删除配置项。
git config [--global] --unset user.name
git config [--global] --unset user.email若加上 --global 选项那么命令会删除全局配置中的相关设置。全局配置通常位于你的用户家目录下的 .gitconfig 文件中。 若不加 --global 选项该命令会删除当前 Git 仓库的 .git/config 文件中的相关设置。 演示如下 Git默认的输出是单一颜色的不容易阅读但其支持用多种颜色来显示其输出的信息运行以下命令来开启多颜色输出
git config --global color.status auto
git config --global color.diff auto
git config --global color.branch auto
git config --global color.interactive autogit config --global color.ui auto也可以一次性设置。如果要删除也使用--unset指令。
2.3、认识工作区、暂存区、版本库 工作区 你在本地计算机上直接进行项目开发和文件编辑的区域。它通常是一个目录其中包含了项目的所有文件和子目录。 暂存区 stage或index。一般存放在. git目录下的index文件(.git/index) 中我们把暂存区有时也叫作索引(index) 版本库 又名仓库repository。 工作区有一个隐藏目录.git, 它不算工作区而是Git的版本库。这个版本库里面的所有文件都可以被Git管理起来每个文件的修改、删除Git都能跟踪以便任何时刻都可以追踪历史或者在将来某个时刻可以“还原”。 在Git中工作区、暂存区和版本库之间的交互是通过Git命令来完成的。一般不允许手动修改.git下的目录文件 2.4、文件修改新增、修改、删除
2.4.1、添加文件演示 git add、git commit、git log、git cat-file 1、相关操作及指令学习 git add 命令可以将⽂件添加到暂存区中
git add [file1] [file2] ... #添加⼀个或多个⽂件到暂存区
git add [dir] #添加指定⽬录到暂存区包括⼦⽬录
git add . #添加当前⽬录下的所有⽂件改动到暂存区git commit 命令将暂存区内容添加到本地仓库中
git commit -m message #提交暂存区全部内容到本地仓库中
git commit [file1] [file2] ... -m message # 提交暂存区的指定⽂件到仓库区-m 选项后跟上本次提交需要描述的信息一般由用户自己设置。这部分内容是对这些文件的细节解释因此不能省略且要好好描述。 git log 命令查看下历史提交记录。该命令显示从最近到最远的提交日志每个提交都包含其哈希值、作者信息、提交日期和提交消息。其可跟随一些选项可看需求了解学习 2、上述操作对于工作区、暂存区、版本库有何变化 总览变化 先来简单了解一下HEAD指针 如何看这里的commit id分成2部分其前2位是文件夹名称后38位是文件名称。 找到这个文件后⼀般不能直接看到里面是什么该类文件是经过 sha 安全哈希算法加密过的文件。可以使用 git cat-file 命令来查看版本库对象的内容。 由上述内容可以看出Git实际管理的并不是文件而上文件中的修改变动。
对于 commit 对象它会显示提交信息
对于 tree 对象它会显示目录树的内容
对于 blob 对象它会显示文件的内容。2.4.2、修改文件演示 git status、git diff 1、总述 git status 和 git diff 是 Git 版本控制系统中两个常用的命令用于查看仓库的当前状态以及比较工作目录、暂存区staging area和提交之间的差异。 2、git status指令介绍 git status 命令用于显示工作区和暂存区的状态。它告诉你有哪些更改已经被暂存staged哪些更改还没有被暂存unstaged以及哪些文件在仓库中但是被删除了。 运行 git status 时会看到以下几种输出
Changes to be committed这部分列出了你已经暂存git add的更改。
Changes not staged for commit这部分列出了你已经修改但还没有暂存的更改。
Untracked files这部分列出了你新创建的文件但还没有被 Git 跟踪。3、git diff指令介绍 git diff 命令用于比较文件或目录的差异。它有多种用法但最基本的用法是显示工作区中的更改与暂存区之间的差异。 git diff [file]显示工作目录中的更改与暂存区之间的差异。显示的格式正是Unix通用的diff格式。 git diff --cached 或 git diff --staged显示暂存区与上一次提交之间的差异。 git diff HEAD [file]显示工作目录中的更改与上一次提交之间版本库中的差异与 git diff 相似但更明确。 2.4.3、版本回退演示 git reset、git reflog 1、相关指令学习 之前提到过Git 能够管理文件的历史版本这也是版本控制器重要能力体现。如何做到 git reset命令用于回退版本可以指定退回某⼀次提交的版本。这里的 “回退”主要是将版本库中的内容进行回退工作区或暂存区是否回退由命令参数决定。
git reset [--soft | --mixed | --hard] [HEAD]--soft 参数对于工作区和暂存区的内容都不变只是将版本库回退到某个指定版本。 --mixed 为默认选项使用时可以不用带该参数git reset [HEAD]。该参数将暂存区和版本库的内容退回为指定提交版本内容工作区文件保持不变。 --hard参数将暂存区、工作区与版本库都退回到指定版本。切记工作区有未提交的代码时不要用这个命令因为工作区的回滚会导致没有提交的代码也一起被回退结果就是容易找不回来所以使用 该参数前一定要慎重。 具体解释 这三个参数均会对版本库做回退本来该指令就是用来回退版本库的变是必然其它是附带需求。 --soft重置位置的同时保留 working Tree工作目录 和 index暂存区的内容只让repository中的内容和 reset 目标节点保持一致因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变暂存区原有的内容也不变只是原节点和Reset节点之间的所有差异都会放到暂存区中。 --mixed默认重置位置的同时只保留 Working Tree工作目录的內容但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。 --hard重置位置的同时直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容所以效果看起来等同于清空暂存区和工作区。 HEAD 参数说明 1、可直接写 commit id表示指定退回的版本 2、可以使用 ^表示HEAD 指当前版本HEAD^ 上⼀个版本HEAD^^ 上上⼀个版本以此类推。PS直接使用git reset HEAD表示将工作区和暂存区回退到与当前版本库相同 3、可以使用 ~数字表示HEAD~0 指当前版本HEAD~1 上一个版本HEAD^2 指上上⼀个版本HEAD^3 指上上上一个版本以此类推。 代码演示 Git 中还提供了一个命令git reflog 可以对此补救一下。该命令显示了你仓库中引用通常是 HEAD、分支和远程分支的更改记录。这些记录包括了你何时创建或删除了分支、何时移动了 HEAD例如通过 git checkout、git merge、git reset 等命令以及何时执行了其他影响引用的操作。 但这并不代表可以高枕无忧实际开发中由于周期时间长极有可能会导致 commit id 等早已经分辨不清找不到。因此才有之前所说慎用--hard选项。 2、原理简述 reset 的本质 Git 的版本回退速度非常快这是因为 Git 在内部有个指向当前分分支此处是master的HEAD 指针。实际执行该指令时是移动 HEAD 并且「捎带」上 HEAD 所指向的 branch如果有的话。
2.4.4、撤销修改
2.4.4.1、基础说明 在Git中撤销修改操作需要根据不同需求而定。
工作区暂存区版本库方法√×未 add ×未commit①git diff对比手动删除不推荐②git checkout – [file]√√已 add×未commitgit reset – hard、git rest – mixted回到情况一√√已 add√已 commitgit reset --hard HEAD^ 2.4.4.2、撤销情况一尚未 add 的代码只存在工作区 如果我们在工作目录中做了一些修改但还没有暂存即还没有使用git add命令此时想要撤销修改可以使用git checkout -- file命令。这会丢弃工作目录中该文件的所有修改使其与HEAD最后一次提交中的版本保持一致。
git checkout -- filename2.4.4.3、撤销情况二已经 add 但没有 commit 的代码存在于工作区、暂存区 如果我们已经使用git add命令暂存了修改但还没有使用commit提交此时可以使用git reset命令来撤销暂存。这会将修改从暂存区中移除但保留在工作目录中。
git reset HEAD filename # 若需要继续撤销工作区内容可以使用 git checkout -- filename即回到了上述情况一。
git reset --mixed HEAD filenmame # 情况同上--mixed 是默认参数使⽤时可以省略git reset --hard HEAD filename # 也可以使用该选项直接回退工作区和暂存库2.4.4.4、撤销情况三已经 add 并且commit 的代码存在于工作区、暂存区、版本库 如果你已经提交了修改并希望撤销这次提交你可以使用git revert命令或git reset命令。使用git reset这会重写历史将HEAD指针移回到之前的提交。
git reset --hard HEAD~1
git reset --hard HEAD^
git reset --hard [commit ID]条件限制使用上述指令回退是有条件的。根据我们很久之前学习的git 三板斧git push会将本地仓库的代码推送到远程仓库中。如果我们想要使用上述指令撤销文件需要在还没有把本地版本库推送到远程前即尚未使用git push操作前才能有效撤销。 2.4.5、删除文件 在 Git 中删除也是⼀个修改操作。可以通过如下两种方式完成 1、使用文件系统的 rm 命令删除文件
rm [filename]
#filename要删除的文件名以及路径。如果你正在当前目录中删除文件则可以只输入文件名。使用文件系统的删除命令此时 Git 并不会立即知道这个文件已经被删除。当我们尝试提交更改时Git 会告诉你有一个未跟踪的文件被删除了除非之前已经暂存了这个文件的删除。为了将文件的删除操作提交到 Git 仓库需要先告诉 Git 文件已经被删除可以通过 git add 命令的 --all 或 -A 选项来实现它会添加所有修改包括新文件、修改的文件和删除的文件。
git add --all
git add -A
git commit -m XXX
#即rm删除后需要再次 git add、git commit相关演示 2、使用 Git 的 git rm 命令删除文件git rm [filename] 命令会删除文件系统中的文件并将这个删除操作添加到暂存区。这意味着我们可以直接提交(commit)这个更改而无需再次使用 git add 命令。 相关演示 3、分支管理
3.1、理解分支git branch 1、概念理解 在Git中分支Branch是一个指向提交对象的指针它代表了一个独立的工作流或开发线。Git中的分支允许开发者在开发过程中进行并行工作而不会相互干扰。 这就类似于你生活在一个多元宇宙中其中存在无数个平行世界每个世界都基于某个初始点即“大爆炸”或起源发展而来但它们各自有着独特的历史、事件和生命轨迹。 在这个多元宇宙中每个平行世界都可以看作是Git中的一个分支。每个分支都是从主世界即Git中的主分支或master分支尽管现在很多团队更倾向于使用main分支作为默认分支的一个时间点即某个提交分叉出来的。 2、如何查看分支相关指令介绍 我们如何查看当前本地的所有分支可以使用如下指令
git branch执行 git branch 命令而不带任何参数时它会列出仓库中所有的本地分支。 当前活动的分支前面会有一个星号*标记。 在之前我们介绍过HEAD 是一个特殊的指针默认指向master分支。实则这种表述方式不太严谨。 HEAD 指针可以指向其他分支被指向的分支就是当前正在工作的分支该分支指向最新一次提交。 即严格意义上 HEAD 实际上是指向该分支的引用而不是直接指向提交。 例如如果你检出了 master 分支那么 HEAD 就会指向 master 分支而 master 分支又指向最新的提交(如下图)。这意味着你可以通过 HEAD 来访问当前分支的最新提交。 通过查看当前的版本库我们也能清晰的理出思路
3.2、分支基本操作
3.2.1、创建分支git branch new-branch 1、相关指令介绍 Git支持我们查看或创建其他分支
git branch new-branch
# new-branch 是新创建的分支的名字演示如下 如上图我们演示了如何用git branch创建一个新分支但同时我们也发现所创建出来的新分支dev和master指向同一个修改。这是为什么 2、如何理解创建的新分支 git branch 创建一个新的分支时这个新分支默认会指向当前 HEAD 所指向的提交。换句话说新分支将会基于你当前所在的分支或提交来创建。例如例如如果你在 master 分支上执行 git branch feature-branch那么 feature-branch 将会指向 master 分支的最新提交。 3.2.2、切换分支git checkout/git switch new-branch 、git checkout -b 1、相关指令介绍 那么如何切换到其它分支下进行开发呢可以使用 git checkout 命令来切换分支。此外从 Git 2.23 版本开始也可以使用 git switch 命令来切换分支。
# new-branch 是分支名# 使用 git checkout 切换分支
git checkout new-branch # 使用 git switch 切换分支Git 2.23
git switch new-branch演示如下 补充 此外我们还可以使用 git checkout -b 指令创建一个新的分支并立即切换到该分支。 2、演示在新分支下开发 现在让我们在新分支下进行文件操作并提交到版本库中看看会发生什么 结论 当我们在某个分支中对文件进行修改并提交这些更改时该分支的引用或者说指针将会更新为指向这次提交所创建的新提交对象。 这种机制使得 Git 能够跟踪每个分支的历史和进度。每个分支都有自己的提交历史而 HEAD 指针则能够帮助我们了解当前正在哪个分支上工作以及该分支的最新状态是什么。
3.2.3、合并分支与合并冲突git merge、 git log --graph 1、演示合并分支 为了在master主分支上能看到新的提交就需要将dev分支合并到master分支。在 Git 中通常使用 git merge 命令来完成。
git merge new-branch
# 表示将指定分⽀new-branch合并到当前分支中。注意 这里若要将dev分支合并到master分支中我们需要在master分支中来使用这个指令。 演示分支合并不存在冲突的情况 PS不是每次合并都能 Fast-forward后续会介绍到其他方式的合并。 2、演示分支合并冲突 使用git merge指令后Git 会尝试自动合并两个分支之间的差异。如果两个分支修改了同一个文件的同一部分Git 会尝试合并这些更改。如果合并过程中出现冲突Git 会停下来并提示你手动解决这些冲突。 解决合并冲突的方案 如果合并过程中出现冲突Git 会在合并后的文件中标记出冲突的部分。这时需要我们手动编辑这些文件解决冲突然后再次提交更改。 解决冲突后需要再次使用 git add 命令将文件标记为已解决并使用 git commit 命令来提交合并结果。 注意根据上述演示可知合并操作是单向的。 git merge主要是将一个分支通常称为“源分支”或“要合并的分支”的更改集成到另一个分支通常称为“目标分支”或“当前分支”中而这个过程不会改变源分支的指向或其历史记录。 以下为上述合并的基本流程
1、我们有一个目标分支比如 main 或 master这是希望将更改合并到的分支。此外我们还有一个源分支比如 feature-branch这个分支包含了想要合并到目标分支的更改。2、执行合并操作需要切换到目标分支使用 git checkout 或 git switch。运行 git merge命令来合并源分支的更改到目标分支。Git 会尝试将这些更改集成到目标分支如果过程中出现冲突Git 会提示手动解决。一旦合并完成包括任何手动冲突解决目标分支就会包含源分支的更改并且这些更改会被添加到目标分支的提交历史中。但是源分支feature-branch的指向和内容不会改变。它仍然指向它之前的最后一次提交包含它之前的所有更改。 3、其它补充 关于上述合并的分支情况用带参数的git log也可以看到。 git log --graph --prettyoneline --abbrev-commit--graph显示一个 ASCII 图形表示以便可以看到分支和合并历史。 --prettyoneline以一行格式显示每个提交包括提交哈希和提交消息的第一行。 --abbrev-commit使用缩写的提交哈希值通常显示前几位字符默认为 7 位但可以通过 --abbrev 指定其他长度。 如果dev分支使用完毕后不再需要可以将该分支删除。
3.2.4、删除分支git branch -d 要删除一个分支可以使用 git branch -d 命令或者 -D 强制删除一个未合并的分支。
# 删除已合并的分支
git branch -d old-branch # 强制删除未合并的分支
git branch -D old-branch演示与细节理解 3.2.5、选择分支合并模式- - no - ff 1、前情回顾与问题描述 在之前使用git merge合并分支时我们简单提到过Git 会采用 Fast forward 模式合并分支。这通常会执行一个快进合并意味着Git只是简单地移动master分支的指针到dev的最后一个提交而不是创建一个新的合并提交。 在这种Fast forward 模式下如果在合并后删除了源分支(dev)目标分支(master)不会记录源分支的任何历史信息丢失。那么当我们在目的分支(master)中使用git log查看历史分支信息时会导致我们无法辨别某次提交到底是由merge合并进来的还是在当前分支正常提交的 2、非Fast forward模式合并 针对上述问题我们只需在使用git merge合并时增加一个选项即可git merge --no-ff --no-ff选项用于强制Git在合并时创建一个新的合并提交。这有助于保持一个更清晰的提交历史因为每个特性分支的合并都会有一个与之关联的合并提交。
优势说明
1、合并历史更加清晰使用--no-ff选项可以清晰地看到哪些提交是来自于哪个分支的以及这些分支是如何合并的。
2、便于回滚和审查由于有明确的合并提交所以在需要回滚或审查合并内容时可以更容易地找到相关的提交。
3、保留分支信息即使删除了合并的分支由于合并提交的存在仍然可以保留该分支的历史信息。相关演示如下 3.3、分支管理策略
3.3.1、分支策略 在软件开发的项目管理中分支策略扮演着至关重要的角色。为了确保项目的顺利进行和版本的稳定发布一般会按照以下基本原则进行分支管理 首先master 分支应保持高度的稳定性。这意味着该分支主要用于发布最新稳定的版本且在日常开发中应避免直接在其上进行修改或提交代码。 它代表了项目的最新稳定状态并作为所有其他分支的基准。 那么日常的开发工作应该在哪里进行呢答案是 dev分支。dev 分支作为主要的开发分支用于承载开发过程中的不稳定代码。团队成员在此分支上进行日常的开发、测试和修复工作。 当项目达到某个重要里程碑如准备发布1.0版本时我们会将 dev 分支上的代码合并到 master 分支并通过 master 分支发布新版本。 在团队协作中每个团队成员都应在自己的独立分支上进行工作。这些分支可以基于 dev 分支创建允许个人自由地进行代码修改和测试。 个人的工作完成并经过验证后可以将自己的分支合并到 dev 分支以便与其他团队成员的工作进行集成。这种工作方式既保证了代码的隔离性又促进了团队成员之间的协作和代码共享。 因此团队合作的分⽀看起来就像这样 3.3.2、bug分支git stash、git stash list、git stash pop等
3.3.2.1、准备工作与如何使用bug分支 问题描述假如我们现在正在dev2分支上进行开发开发过程中发现master分支上有待解决的紧急bug。然而dev2的代码在工作区中已经开发了一半尚未完全无法提交此时该如何做 回答可以建立一个新的临时分支来修复bug。 但在此之前要先保存dev2分支的工作区代码
git stash
git stash listGit提供了git stash 命令这会保存当前工作目录和暂存区的所有更改并返回到一个干净的工作状态。被储藏的内容可以在将来某个时间恢复出来。 此外 git stash list 命令可以列出所有被 git stash 保存的暂存变更stash entries。每个 entry 都有一个唯一的名称通常是基于时间戳和随机数的组合。 储藏dev2工作区之后由于我们要基于master分支修复bug所以需要切回master分支再新建临时分支来修复bug。 待修复完成后切换到master分支合并fix_ bug修复到master最后删除用于fix_ bug分支其使命已经完成。
3.3.2.2、master分支bug修复后后续dev操作 现在让我们回到dev2分支中并恢复工作。 若之前使用了git stash来保存暂存变更(stash entries)可以使用下述指令恢复工作
# 重新将暂存恢复
git stash pop # 恢复entry并将其从 stash 列表中移除
git stash apply # 恢复但不会从 stash 列表中移除该 entry# 删除暂存
git stash drop # 显示
git stash list
git stash show这些命令的用法
若有一些未提交的变更可运行 git stash 来保存这些变更。查看所有保存的暂存变更git stash list若决定重新应用其中一个 stash entrygit stash apply stash{0}其中 stash{0} 是待想要重新应用的 stash entry 的名称。也可以使用git stash drop。若决定删除一个 stash entrygit stash drop stash{1}其中 stash{1} 是你想要删除的 stash entry 的名称如果git stash pop、 git stash apply 、 git stash drop 、后面没有跟随具体的 stash entry 名称直接使用那么 Git 默认会使用最近的一个 stash entry通常是列表中的第一个stash{0}。 一个问题dev2分支完成开发提交后是否能直接合并到master上 回答 1、在先前的bug修复中fix_bug是在dev2之后创建的其在mster分支中合并后master分支目前最新的提交是要领先于新建dev2时基于的master分支的提交的。这就意味着我们在dev2中是看不见修复bug的相关代码的。 2、如果直接合并dev2到master上那么正常情况下我们切回master分支进行合并即可但这样其实是有一定风险的。这是因为在合并分支时可能会有冲突而代码冲突需要我们手动解决这意味着我们需要在master分支上解决冲突。由于在实际的项目中代码冲突并非一两行那么简单有可能几十上百行甚至更多我们无法保证对于冲突问题可以正确地一次性解决掉甚至在解决的过程中手误出错导致错误的代码被合并到master上。 3、因此这里我们建议最好在自己的分支上合并下master再让master去合并dev。这样做的目的是有冲突可以在本地分支解决并进行测试而不影响master。 这里我们演示[建议]中的做法
4、远程操作
4.1、分布式版本控制系统 1、理解分布式版本控制系统 我们目前所介绍到的Git内容(工作区暂存区版本库等等) 都是在当前本地主机上的上。然而 Git 其实是一个分布式版本控制系统Distributed Version Control System, DVCS。它允许开发者在本地存储所有的版本历史、分支和标签而不是依赖于一个中央服务器。每个开发者的本地仓库都包含完整的项目历史 因此他们可以在没有网络连接的情况下进行工作并且可以随时与其他开发者同步更改。 2、理解远程仓库 Git 这种分布式版本控制系统其核心特性在于同一个 Git 仓库可以分散部署在不同的机器上。 在最初时通常只有一台机器拥有一个原始版本库但此后其他机器可以通过“克隆”操作获取该原始版本库的完整副本。而且每台机器上的版本库都是相同的没有主从之分它们各自拥有完整的项目历史记录和版本信息。 对于仅拥有一台电脑的用户而言虽然理论上可以在同一台电脑上克隆多个版本库只要这些库位于不同的目录但在实际场景中这样做并无太大意义因为这样不仅不能充分利用分布式版本控制系统的优势反而增加了数据丢失的风险例如硬盘故障可能导致所有库同时受损。 在实际应用中通常的做法是选择一台机器作为服务器该服务器保持24小时开机状态并作为中心仓库。其他开发者从该“服务器”仓库克隆代码到自己的电脑上进行开发完成开发后再将各自的提交推送到服务器仓库并从服务器仓库中拉取其他开发者的提交以保持代码同步。 搭建自己的 Git 服务器固然可行但对于初学者而言这可能会增加学习难度。幸运的是存在许多提供 Git 仓库托管服务的平台如 GitHub、码云Gitee等代码托管平台。 这里主要介绍如何使用码云远程仓库进行版本控制操作。
4.2、远程仓库
4.2.1、新建远程仓库 略。 以前博文介绍过相关链接。
4.2.2、克隆远程仓库git clone 1、基本介绍 克隆/下载远端仓库到本地需要使用git clone 命令后面跟上我们的远端仓库的链接。远端仓库的链接可以从仓库中找到选择“克隆/下载”获取远程仓库链接。 SSH协议和HTTPS协议是Git最常使用的两种数据传输协议。 SSH 协议使用了公钥加密和公钥登陆机制体现了其实用性和安全性使用此协议需要将我们的公钥放上服务器由Git服务器进行管理。使 用HTTPS方式时没有要求可以直接克隆下来。 2、实操 HTTPS方式之前博文介绍过。(实际打开克隆界面也会有提示按照要求来即可) SSH方式此处略详细操作步骤可自行搜索了解。这里只做一些简单说明。 1、使用SSH方式克隆仓库若没有添加公钥到远端库中服务器会拒绝我们的clone链接。 2、对此需要设置一下创建SSH Key在用户主目录下看看有没有.ssh目录如果有再看看这个目录下有没有id_ rsa和id_ rsa.pub这两个文件如果已经有了可直接跳到下一步。如果没有需要创建SSH Key:
ssh-keygen -t rsa -C 1234578123.com #这里输入的邮箱和你远程仓库处用户邮箱相同上述指令顺利完成我们可以在用户主目录里找到.ssh目录,里面有id_ rsa和id_ rsa.pub 两个文件。它们个就是SSH Key的秘钥对id_ rsa 是私钥不能泄露出去id_ rsa. pub是公钥可以公开。 3、如果有多个人协作开发GitHub/Gitee 允许添加多个公钥只要把每个人的电脑上的Key都添加到GitHub/Gitee就可以在每台电脑上往GitHub/Gitee上提交推送了。
4.2.3、查看远程库信息git remote 1、origin远程仓库名 使用 git clone 命令克隆一个远程仓库时Git 会自动将这个远程仓库命名为 origin并且会将 origin 设置为默认远程仓库。这个名称 只是一个约定俗成的名字用于表示我们克隆的原始仓库可以根据需要将其重命名或添加其他远程仓库。 如果需要重命名 origin 或添加其他远程仓库可以使用以下命令 git remote rename origin newname将默认的 origin 远程仓库重命名为 newname。 git remote add newname url添加一个新的远程仓库并命名为 newname。这里的 是远程仓库的 URL。 2、git remote命令 git remote命令可以查看所有已配置的远程仓库引用默认为 origin但你可以添加更多。 git remote -v 命令-v 代表 --verbose即详细信息可以查看每个远程仓库引用的 URL 和与之关联的别名。 如下图我们只有 origin 远程仓库分别用于 fetch拉取和 push推送的 URL通常这两个 URL 是一样的。 4.2.4、向远程仓库推送git push 1、相关指令介绍 在Git中当我们完成了一些本地更改例如添加了一些文件、修改了代码等并想要将这些更改推送到远程仓库时可以使用git push命令该命令用于将本地的分支版本上传到远程并合并命令格式如下:
git push 远程主机名 本地分⽀名:远程分⽀名# 如果本地分⽀名与远程分⽀名相同则可以省略冒号
git push 远程主机名 本地分⽀名例如我们本地仓库名称为origin修改的内容在master分支中此时要将其推送远程仓库master分支中则有git push origin master:master由于这里本地分支名与远程分支名相同也可以写成git push origin master 2、注意事项 1、这里需要注意如果我们之前设置过全局的 user.email 和user.name这两项配置需要和 gitee 上配置的用户名和邮箱⼀致否则会出错。或者从来没有设置过全局的 name 和 e-mail那么我们第⼀次提交时也会报错。这时就需要我们配置一下相关操作见2.1.1章节。 2、直接使用 git push若只输入 git push并且没有指定任何参数时Git 会尝试推送当前所在的分支到其追踪的远程分支如果设置了的话。这通常是在我们已经设置了上游upstream分支的情况下使用的例如当我们克隆了一个远程仓库或者首次向远程仓库推送分支时Git 会自动设置本地分支以追踪相应的远程分支。
4.2.5、拉取远程仓库git pull 当远程仓库是要领先于本地仓库一个版本时为了使本地仓库保持最新的版本我们需要拉取远端代码并合并到本地。Git 提供了git pull 命令该命令用于从远程拉取fetch 代码并 合并merge 本地的版本。格式如下:
git pull 远程主机名 远程分⽀名:本地分⽀名# 如果远程分⽀是与当前分⽀合并则冒号后⾯的部分可以省略。
git pull 远程主机名 远程分⽀名演示如下 4.2.6、配置Git忽略特殊文件.gitignore 在日常开发中有些文件我们不想或者不应该提交到远端如日志文件、编译生成的中间文件、配置文件中的敏感信息等。对于此情况Git在工作区的根目录下创建一个特殊的. gitignore文件用于指定不希望被Git追踪的文件或目录。 创建.gitignore文件 如果我们已经有一个.gitignore文件可以直接编辑它。 实际我们不需要从头写. gitignore文件, gitee在创建仓库时就可以为我们生成需要我们主动勾选。当然也可以自行创建但要注意创建的目录必须在工作区的根目录下。 指定要忽略的文件或目录 在.gitignore文件中我们可以添加一行来指定一个要忽略的文件或目录。每行一个条目。 我们可以使用通配符和模式来设置 .gitignore文件例如
*.a 忽略所有以.a结尾的文件。
!lib.a 但不忽略lib.a文件注意前面的!表示取反。
/todo.txt 只忽略仓库根目录下的todo.txt文件而不忽略子目录中的todo.txt文件。
build/ 忽略build/目录及其所有内容。
doc/*.txt 忽略doc/目录下所有.txt文件。其它详细内容见链接gitignore
5、标签管理
5.1、理解标签 1、是什么 在Git中标签tags是一种非常重要的引用类型它们指向某个特定的提交通常用于标记发布点如v1.0、v2.5等。与分支branches不同标签通常不会随着新的提交而移动它们被设计为指向代码库中的一个固定点。 2、有何用 那么标签有什么用呢简述感性认识 可读性 相较于难以记住的commit id一串长而复杂的哈希值tag通常是一个简短的、有意义的名称如“v1.0”或“release-candidate”这使得它们更易于理解和记忆。 标记重要版本 通常,标签用于标记项目中的重要版本如发布版本、里程碑或修复了关键问题的版本。这些标签使得团队成员和其他利益相关者能够轻松地找到和引用这些特定的版本。 历史追踪 此外随着项目的不断发展会有多个版本发布**。通过为每个版本设置标签可以轻松地追踪和识别不同的版本。** 这对于了解项目的历史、比较不同版本之间的差异以及回滚到以前的版本都非常有用。
5.2、标签相关操作
5.2.1、创建与查看标签git tag、git show 1、标签分类 Git中有两种类型的标签轻量标签Lightweight Tag 和附注标签Annotated Tag 。 轻量标签Lightweight Tag 轻量标签只是指向特定提交的引用。它们是最简单的标签形式只是一个指针没有额外的信息。创建轻量标签时只需指定标签名称和目标提交即可。 附注标签Annotated Tag 附注标签是包含额外信息的对象其中包括标签的作者、创建日期、标签消息等。创建附注标签时会创建一个独立的Git对象存储标签的信息并将其与特定提交关联。 2、创建标签本地 创建轻量级标签
git tag tag_name [commit_hash]#tag_name必须指定创建的标签名称。
#commit_hash可选指定为某次提交创建标签不指定则默认为最近一次提交。创建附注标签
git tag -a tag_name -m tag_message [commit_hash]#tag_name必须指定创建的标签名称。
#tag_message必须指定附注标签的消息。
#commit_hash可选指定为某次提交创建标签不指定则默认为最近一次提交2、查看标签 查看本地仓库的标签列表
git tag [-l search_rule]# -l search_rule可选用于列出匹配特定模式的标签。
# 例如git tag -l v1.*将列出所有以v1.开头的标签。查看远程仓库的标签列表
git ls-remote --tags remote_repo# remote_repo必须指定远程仓库一般为origin。查看标签详情内容
git show tag_name# tag_name必须指定需要查看详情的标签名称。5.2.2、推送标签到远端git push 在本地创建的标签不会自动推送到远程。如果要推送某个标签到远程可使用下述命令
git push remote_repo tag_name# remote_repo必须指定远程仓库一般为origin。
# tag_name必须指定需要同步到远程仓库的标签名称。如果本地有很多标签也可以一次性的全部推送到远端
git push origin --tags5.2.3、删除标签git tag -d、git push --delete 删除本地仓库标签
git tag -d tag_name# tag_name必须指定需要删除的标签名称。删除远程仓库标签 使用--delete 选项删除
git push remote_repo --delete tag_name# remote_repo必须指定远程仓库一般为origin。
# tag_name必须指定需要删除的标签名称使用冒号:语法删除这条命令与 --delete 选项等效
git push remote_repo :refs/tags/tag_name# remote_repo必须指定远程仓库一般为origin。
# tag_name必须指定需要删除的标签名称Fin、共勉。
