Git入门到精通
git是什么
Git 是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。
开源:软件的源代码对公众开放,任何人都可以查看、修改和分发源代码
分布式:在版本控制系统中,意味着每个开发者都有完整的代码仓库副本,包括项目的所有历史记录。每个开发者都可以在本地进行提交、分支等操作,然后通过推送或拉取操作与其他开发者共享更改。
版本控制系统:是一种用于记录和管理文件或项目代码变更的工具。它允许开发者追踪文件的修改历史,包括谁在何时进行了哪些更改。版本控制系统的核心功能包括:
记录变更:保存每次修改的详细信息,便于回溯和比较不同版本之间的差异。
分支管理:创建多个独立的开发分支,以便同时进行不同的功能开发或修复不同类型的错误。
合并代码:将不同分支的更改合并到一个主分支中,解决可能的冲突。
协同工作:支持多个开发者同时对同一项目进行修改,提高团队协作效率。
工作流
安装
参考这篇博客
Git 详细安装教程(详解 Git 安装过程的每一个步骤)_git安装-CSDN博客
托管平台
github,gitlab,gitee都是基于git的代码托管平台,提供了远程仓库来存储代码,并且在 Git 的基础上增加了许多协作和管理功能。
这么多平台,我该怎么选择呢?
GitHub
-
功能:就像一个巨大的代码仓库,全球的程序员都可以把写的代码存到这里,还能看到别人写的代码,互相学习、借鉴和合作。它有很多工具,方便大家一起完成一个项目,比如可以讨论代码的问题、分配任务等。
-
使用场景:适合全球范围的团队合作,尤其是开源项目。比如,一个程序员在全世界都有合作伙伴的项目,大家就可以通过 GitHub 一起写代码、修改代码。
-
适用人群:全球的程序员,尤其是那些参与开源项目或者和国外团队合作的程序员。
GitLab
-
功能:和 GitHub 类似,也是一个代码仓库,但它更注重代码从写到上线的整个过程。比如,可以自动检查代码有没有问题,还能直接把代码部署到服务器上。
-
使用场景:适合企业内部的开发团队,尤其是那些需要严格管理代码和开发流程的企业。比如,一个公司的开发团队,他们需要确保代码的质量和安全,就可以用 GitLab 来管理整个开发流程。
-
适用人群:企业内部的开发团队,特别是对开发流程要求严格的团队。
Gitee
-
功能:也是代码仓库,但它是专门为中国程序员设计的。它的界面是中文的,而且在中国的网络环境下访问速度更快。它也有很多方便的工具,比如可以快速生成文档、管理项目等。
-
使用场景:适合中国的团队合作,尤其是网络环境不太好的情况下。比如,一个中国的创业团队,他们需要快速地写代码、测试代码,就可以用 Gitee 来提高效率。
-
适用人群:中国的程序员,尤其是网络环境受限或者更习惯中文界面的程序员。
注意:注册账号时要使用英文名称
三大区域
工作区:工作区是项目的当前目录,就是你正在操作的文件夹
分为两部分:已管理,已经生成版本;新文件,已修改的文件
git自动将文件分类
暂存区:暂存区是一个中间区域,它是一个文件,保存了下次将要提交到本地仓库的文件列表信息。通过add管理=>存入了暂存区的文件是绿色的
版本库:本地仓库是存储在你本地计算机上的完整版本库,它包含了项目的所有提交历史、分支信息等。通过commit实现
场景
前情提要:
你是一个刚进入公司的实习生,抱着忐忑紧张的心情,你接受了上级下发的任务“熟悉一下代码,过几天有几个bug要你改”,你知道需要用到git,但是好像忘完了!!!这该怎么办,于是你按照下面的步骤进行操作
一、拉取项目并运行
你该怎么把代码存入到你的电脑里呢?
这个时候你要将项目拉取下来
先打开这个项目所用的托管平台比如github,注册或登录账号,点进项目
会看到这样一个页面
点击code,复制HTTPS或者SSH下的地址
HTTPS、SSH区别
认证方式
-
HTTPS:需要输入 GitHub 账户的用户名和密码(或个人访问令牌)进行认证。
-
SSH:需要提前在本地生成 SSH 密钥,并将公钥添加到 GitHub 账户中,之后克隆时无需输入密码。
安全性
-
HTTPS:数据传输过程加密,安全性较高,但密码可能被记录或泄露。
-
SSH:使用密钥对进行加密认证,安全性更高,且避免了密码明文传输的风险。
操作便利性
-
HTTPS:无需提前配置,直接使用 GitHub 账户信息即可克隆。
-
SSH:需要先生成和配置 SSH 密钥,过程稍复杂,但后续操作无需频繁输入密码。
适用场景
-
HTTPS:适合偶尔克隆项目或在不便于配置 SSH 的环境中使用。
-
SSH:适合频繁与 GitHub 交互的开发者,提供更安全和便捷的体验。
设置SSH密钥
git设置SSH密钥_git配置ssh密钥-CSDN博客
-
新建一个文件夹,将来用于存放拉取下来的项目
git配置完成后,打开文件夹->右键->显示更多
点击后
回车,如果使用HTTPS,会出现一个弹窗,依次输入托管平台的账号名和密码就可以了,没有报错就是拉取成功了
如图
注意:这里的复制粘贴和平时的不一样
复制:ctrl + insert
粘贴:shift + insert
或者直接右键
copy是复制,paste是粘贴
回头再看我们创建的文件夹中已经出现了刚刚拉取的项目,我们可以直接在vscode中打开这个文件夹
要先安装依赖才能运行程序, 如果有read.me文档一定要看一下
如果没有,就直接在终端输入npm i安装依赖,安装成功后运行程序,
一般是npm run serve 或者是npm run dev,具体是哪个后缀打开package.json就可以看到
二、新建分支并提交
项目成功拉取下来了,你想要修改bug,但是你不能直接在别人的分支下做出修改,你需要创建一个属于你的分支,你每次更新后的代码都要推送到你自己创建的分支上
什么是分支
Git 分支管理是 Git 强大功能之一,能够让多个开发人员并行工作,开发新功能、修复 bug 或进行实验,而不会影响主代码库。
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。各分支之间相互隔离,不影响。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
实际项目开发时,主分支是已经上线的部分,用户直接可以看到并使用,如果要开发新功能,一般是基于develop分支创建自己的分支,自己负责的模块功能完成后确认没有错后合并到develop分支上,等待develop分支功能完善后再合并到主分支并上线
常见指令
查看远程分支
git branch -r
查看所有分支
git branch
创建新分支
git branch 分支名
切换到指定分支
git checkout 分支名
创建分支并切换到该分支
git checkout -b 分支名
查看所有本地和远程分支:
git branch -a
从远程仓库获取最新的分支信息和提交记录,但不会自动合并或修改本地的文件
git fetch origin
当你在本地创建了一个新的分支
把他推送到gitlab
git push origin 分支名
或者直接在gitlab中新建分支
三、创建项目并上传本地主分支
你现在已经转正,需要你带队开发一个项目,或者是需要你完成一个小案例,这时候怎么创建一个项目呢?
打开gitlab,点击头像进入个人主页,点击创建项目
我们这里创建一个空白项目,填写好项目名称,项目标识串(项目描述)点击新建项目
创建成功
在你的电脑上创建一个文件夹,用于存放项目代码
基础框架整理好后,在文件夹中右键打开git Brash框
初始化init,表示git要来管理这个项目了
git init
查看文件状态(红色是有变化的(新增或是修改)、绿色表示git已经管理起来的)
git status
查看具体修改(哪行,修改了什么)
git diff
管理哪些文件到暂存区
git add 文件名//管理指定文件 git add .//管理所有变化的(红色的)文件
将在缓存区中的文件生成新版本
git commit -m '版本描述'
add和commit可以合并
git commit -a -m "版本描述"
查看所有版本
git log
查看工作区和暂存区之间的差异
git diff
查看暂存区和最后一次提交之间的差异
git diff --cached
显示所有分支的提交历史,而不仅仅是当前分支的提交历史。
git log --all
显示提交历史的图形化表示,帮助理解分支和合并的关系。
git log --all --graph
现在回到gitlab,向下翻,有如何推送代码的指令
1、将远程仓库添加到你的本地Git配置中,连接远程仓库并将其命名为origin
,一般叫这个名字,如果忘记自己起的什么名字,
git remote
可以查看,如果想要修改名字
git remote rename 原名 要修改的名字
2、可以方便地将当前分支重命名为 master
,适用于需要统一分支名称的场景。
3、将本地的 master
分支推送到远程仓库 origin
四、更新代码
我们在编写自己分支负责的功能的时候,每完成一个模块就上传到自己的分支上
定期同步 develop 分支
当你在公司进行开发时,develop分支是很多人共同开发的,可能会有其他团队成员的更新。为了保持你的分支与 develop
分支同步,要定期从分支上拉取最新的代码,我们上班要做的第一件事就是重新拉取更新分支
拉取最新的 develop 分支
git checkout develop git pull origin develop
切换回你的分支并合并 develop
git checkout 你的分支 git merge develop
这会将 develop
分支的最新更改合并到你的分支中,帮助你及时发现并解决可能的冲突。
所谓冲突就是,两个分支修改了同一个地方,git不知道要保留哪个,所以需要我们自己做判断
如果出现冲突,Git 会提示你哪些文件有冲突。
git status
冲突会报红
打开这些文件,找到冲突标记并手动解决冲突。
等号上面表示当前分支做出的修改,等号下面表示合并进来的分支做出的修改,我们只能保留一部分,比如我们保留下面的部分,就要把其他的都删掉
解决冲突后,添加解决的文件并提交:
git add 文件名 或 git add . git commit -m "描述信息"
将你的更改推送到远程仓库,以便团队成员可以看到你的进度。
git push origin your-feature-branch
拉取请求
当你完成功能开发并准备好合并到 develop
分支时,创建一个拉取请求(PR),在你的Git托管平台(如GitLab、GitHub等)上,找到你的分支并创建一个PR,目标分支选择为 develop
。如图所示页面
团队成员会在PR中审查你的代码,可能提出修改建议。根据反馈进行必要的调整并推送新的更改。
当PR通过审查并批准后,合并你的分支到 develop
分支。
在远程仓库平台上,点击合并按钮将你的分支合并到 develop
。
删除功能分支(可选)
合并后,可以删除你的功能分支以保持仓库整洁:
git branch -d 你的分支 // 删除本地分支 git push origin --delete 你的分支 // 删除远程分支
如果觉得每次都要输入远程仓库名和分支名比较繁琐的话
git push origin 分支名
可以加一个-u去推送一次
git push -u origin 分支名
这样下次还想在这里推送的话,就输入
git push
五、储藏stash
当你正在开发时,写到一半还没写完,老板说让你去修复一个线上的bug。
这个时候你想checkout切换到master分支是切换不了的,因为你现在还有东西没写完,就是说你现在的工作目录是脏的,他会提示我们进行提交或者是存储
你也可以把你现在写一半的功能进行提交,但是一般来说是不推荐这样做的,切换到正在开发的分支,我们可以通过
git stash
去储藏我们当前所修改的东西,它其实等价于
git stash push
用哪个都可以
现在我们的目录就是一个干净的了
这时候就可以成功切换分支了
apply恢复
当你修改完bug,想要回到你正在开发的分支,先切换回正在开发的分支,通过
git stash apply
恢复我们存储的内容
存储可以用很多次,回看存储记录
git stash list
0表示最后一次存储的东西,1是上一次,2是最开始存储的,倒序排列
如果你想回到某次存储的版本,想要回到哪个版本就输入前面对应的数字
git stash apply stash@{数字}
多次存储时: 代码原来是a,修改了一下是a1,然后stash一下保存的就是a1,然后你修改BUG之后切换回来的时候代码还是原先a的状态,你需要返回到stash{1}的状态才是a1,如果这个时候你直接看代码,代码就原先a的状态。然后你把a改成a2,再stash一下。那就代表有两次stash分别保存的是a1和a2.你可以根据你自己的需要看返回到那个状态。
目录不干净的话是无法apply的,比如你从回到了一个存储的版本,但是你没有做任何操作,想要回到另一个存储的版本,这个时候就无法成功
这里的目录不干净指的是:对某些文件进行了修改、添加了新文件、删除了某些文件 ,但是没有将这些文件提交到git仓库
checkout恢复(慎用)
还有一种恢复stash的方法
git checkout -- 文件名 git stash pop
丢弃工作目录中指定文件的更改,将文件恢复到上次提交的状态,要谨慎使用
-
如果更改未被暂存,
git checkout -- 文件名
会永久丢弃更改。 -
如果更改已被暂存,
git checkout -- 文件名
仅丢弃工作目录中的更改,暂存区中的更改仍然存在。
pop
从暂存区(stash)中取出最近一次暂存的更改,并应用到当前工作目录中。如果应用成功,暂存的更改会被从暂存区移除。
git stash pop
drop
上面的pop会在恢复完成后将暂存区的内容删掉,但是如果我们想直接删掉别的暂存版本,可以通过
git stash drop stash@{数字}
就可以实现指定版本删除
六、回滚
开发新版本的时候,不小心删除了一些重要的东西,不好找回,这时候可以回滚到之前的版本,这能极大地减少损失,同时也提醒我们,完成一个小模块之后就要提交,不仅能方便后续挽救,还能工作留痕
git reset
你可以把git reset
想象成一个“撤销按钮”,它可以让你回到之前的某个版本。
-
git reset --soft <commit>
:这就像你只是把当前的标记移动了一下,但保留了你之前做的修改内容。比如说,你写了一段代码,提交了,然后又做了些修改,现在你想回到之前的提交状态,但还想保留刚刚修改的代码,就可以用这个选项。 -
git reset --mixed <commit>
:这是默认选项,它不仅移动了标记,还会更新暂存区(暂存区可以理解为你准备提交代码的一个中间区域),但保留你工作区(你实际编写代码的地方)的修改。当你想更新暂存区的内容,同时保留工作区的修改时,可以用它。 -
git reset --hard <commit>
:这个操作比较 “强硬”,它会直接把你本地的代码强制改回到某个提交的状态,之前做的所有修改都会丢失。所以用这个命令的时候要特别小心,确保你已经备份了重要的修改内容。
git revert
这个命令就像是一个 “反向操作器”,它会创建一个新的提交,来撤销之前某个提交的更改。比如说,你发现之前某个版本的代码有问题,想把它撤销掉,就可以用这个命令。它的好处是不会改变你之前的历史记录,比较安全。
git checkout
你可以把git checkout
看成是一个 “恢复工具”,它可以帮你恢复文件到之前的状态。
-
git checkout -- <file>
:当你对某个文件做了修改,但发现改错了,想直接丢弃这些修改,恢复到之前的状态,就可以用这个命令。 -
git checkout <commit> -- <file>
:如果你想把某个文件恢复到某个特定版本的状态,就可以用这个命令。比如说,你有一个文件在某个提交版本里是好的,但现在被改坏了,你可以用这个命令把它恢复到那个好的版本。
查看提交历史
-
git log
:查看提交历史记录,找到需要回滚到的提交哈希值。-
git log --oneline
:以简洁模式查看提交历史。
-
-
git reflog
:查看操作日志,记录了你在本地对仓库的所有操作,有助于找回误操作前的状态。
回滚到特定提交
-
使用
git reset
或git revert
回滚到特定的提交。-
如果只是想撤销某个特定的提交,使用
git revert
是更安全的选择,因为它不会改变提交历史。 -
如果需要将整个仓库回滚到某个状态,可以使用
git reset --hard <commit>
,但需谨慎操作,因为这会丢弃该提交之后的所有更改。
-
处理远程仓库
-
如果已经将更改推送到远程仓库,可能需要通知团队成员,或者使用
git push --force
强制推送回滚后的状态,但这可能会导致其他开发者的问题,需谨慎使用。
备份与恢复
-
在进行回滚操作前,建议备份当前状态,以免误操作导致数据丢失。
-
可以通过创建一个新的分支来保存当前状态:
bash复制
git branch backup_branch
实践与案例
-
回滚单个文件:使用
git checkout
或git restore
恢复单个文件到某个提交的状态。 -
回滚整个项目:使用
git reset
或git revert
回滚整个项目到某个提交。 -
撤销最近一次提交:使用
git reset --soft HEAD~1
撤销最近一次提交,但保留工作区的更改。
注意事项
-
谨慎使用
--hard
:git reset --hard
会永久性地丢弃工作区和暂存区的更改,操作前请确保已备份重要更改。
补充内容
变基rebase
可以理解为搬家操作,比如同时开发了一个A分支,你开发了一个B分支,现在两个分支需要在一起进行测试,你可以使用分支合并,也可以采用变基,在这个场景下,两个分支的功能是一样的,这个时候就会把B分支上的东西移到A分支上,相当于搬家,变基操作可以让提交记录变得更好看一些
git checkout B git rebase A
注意:如果你的分支提交到了远程分支上,别人有可能拿你的分支进行二次开发的话,这时候你的分支千万不要再进行变基,相当于你在盖楼,你的同事把你做第一层楼去盖第二层,你如果变基的话,你的同事盖着盖着一楼没了
1. 变基会重写提交历史
变基操作(git rebase
)会将当前分支的提交历史重新应用到指定的基点上。这意味着变基会创建新的提交,从而改变分支的提交历史。
2. 共享分支的提交历史被改变
如果其他人已经基于你的分支进行了开发,他们可能会拉取你的分支并基于你的提交进行新的提交。如果你对你的分支进行了变基,那么你的分支的提交历史会被重写,这会导致以下问题:
-
其他人的提交可能会与你的新提交历史冲突。
-
其他人的工作可能会基于一个已经不存在的提交历史,导致混乱和错误。
3. 可能导致合并冲突
如果其他人已经基于你的分支进行了开发,并且你对你的分支进行了变基,那么在合并时可能会出现大量的合并冲突。这些冲突需要手动解决,增加了开发的复杂性和出错的可能性。
4. 破坏团队协作
在团队协作中,共享分支的提交历史应该保持稳定和一致。如果每个人都随意变基共享分支,会导致提交历史混乱,增加团队协作的难度。
示例场景
假设你有一个分支 feature-branch
,并将其推送到远程仓库。其他团队成员基于你的分支创建了新的分支 feature-branch-extended
并进行了开发。如果你对 feature-branch
进行了变基,那么 feature-branch
的提交历史会被重写。当其他团队成员尝试将 feature-branch-extended
合并到 feature-branch
时,可能会遇到以下问题:
-
提交历史不一致:
-
feature-branch
的提交历史已经被重写,而feature-branch-extended
基于原始的提交历史。 -
这会导致合并时无法正确对齐提交,从而引发冲突。
-
-
代码差异:
-
由于提交历史的不一致,某些代码更改可能在新的提交历史中不存在,导致代码差异。
-
这些差异需要手动解决,以确保代码的正确性。
-
rebase -i
交互式操作
比如输入
git rebase -i head~3
选择前三次提交的一个分支进行编辑,与其说是编辑,不如说是对之前的提交进行修改
按下回车之后,进入了一个交互式页面,可以直接修改
每一个分支前面都有pick,表示我不会修改他们
把pick改成edit,保存退出我们的交互界面,就可以按照提示去修改我们这次的提交
可以直接在这个交互式页面里面删除某一行,就相当于这次提交就直接删除了
我们也可以把一次提交或者多次提交前面的pick改成squash,表示压缩我们这次的提交,并且把我们的修改内容移到前一个提交上面,比较适合我们在开发一个大型项目的时候把这个大型项目进行多次提交融合成一个提交,这里只是举几个例子,这个功能还是很强大的,新手慎用,涉及到重写
cherry-pick
顾名思义就是,像摘樱桃一样
git cherry-pick
命令允许你选择特定的提交并将其应用到当前分支。它在需要从一个分支移植特定更改到另一个分支时非常有用。
如果拣选过程中出现冲突,解决冲突后使用 git cherry-pick --continue
继续拣选。
vscode+git
因为使用工具时可能会遇到一些问题,导致操作失败,最好用的还是原生git命令,有工具确实能方便很多,我们这里简单介绍一下
官方网站:(浏览器无法翻译,比较吃英语底子,可以搭配翻译软件食用)
Using Git source control in VS Code
博客:
基于 VScode 的 git 详细使用指南【保姆级!建议收藏!】_vscode使用git-CSDN博客
git指令大全
git init # 初始化本地git仓库(创建新仓库) git config --global user.name "xxx" # 配置用户名 git config --global user.email "xxx@xxx.com" # 配置邮件 git config --global color.ui true # git status等命令自动着色 git config --global color.status auto git config --global color.diff auto git config --global color.branch auto git config --global color.interactive auto git config --global --unset http.proxy # remove proxy configuration on git git clone git+ssh://git@192.168.53.168/VT.git # clone远程仓库 git status # 查看当前版本状态(是否修改) git add xyz # 添加xyz文件至index git add . # 增加当前子目录下所有更改过的文件至index git commit -m 'xxx' # 提交 git commit --amend -m 'xxx' # 合并上一次提交(用于反复修改) git commit -am 'xxx' # 将add和commit合为一步 git rm xxx # 删除index中的文件 git rm -r * # 递归删除 git log # 显示提交日志 git log -1 # 显示1行日志 -n为n行 git log -5 git log --stat # 显示提交日志及相关变动文件 git log -p -m git show dfb02e6e4f2f7b573337763e5c0013802e392818 # 显示某个提交的详细内容 git show dfb02 # 可只用commitid的前几位 git show HEAD # 显示HEAD提交日志 git show HEAD^ # 显示HEAD的父(上一个版本)的提交日志 ^^为上两个版本 ^5为上5个版本 git tag # 显示已存在的tag git tag -a v2.0 -m 'xxx' # 增加v2.0的tag git show v2.0 # 显示v2.0的日志及详细内容 git log v2.0 # 显示v2.0的日志 git diff # 显示所有未添加至index的变更 git diff --cached # 显示所有已添加index但还未commit的变更 git diff HEAD^ # 比较与上一个版本的差异 git diff HEAD -- ./lib # 比较与HEAD版本lib目录的差异 git diff origin/master..master # 比较远程分支master上有本地分支master上没有的 git diff origin/master..master --stat # 只显示差异的文件,不显示具体内容 git remote add origin git+ssh://git@192.168.53.168/VT.git # 增加远程定义(用于push/pull/fetch) git branch # 显示本地分支 git branch --contains 50089 # 显示包含提交50089的分支 git branch -a # 显示所有分支 git branch -r # 显示所有原创分支 git branch --merged # 显示所有已合并到当前分支的分支 git branch --no-merged # 显示所有未合并到当前分支的分支 git branch -m master master_copy # 本地分支改名 git checkout -b master_copy # 从当前分支创建新分支master_copy并检出 git checkout -b master master_copy # 上面的完整版 git checkout features/performance # 检出已存在的features/performance分支 git checkout --track hotfixes/BJVEP933 # 检出远程分支hotfixes/BJVEP933并创建本地跟踪分支 git checkout v2.0 # 检出版本v2.0 git checkout -b devel origin/develop # 从远程分支develop创建新本地分支devel并检出 git checkout -- README # 检出head版本的README文件(可用于修改错误回退) git merge origin/master # 合并远程master分支至当前分支 git cherry-pick ff44785404a8e # 合并提交ff44785404a8e的修改 git push origin master # 将当前分支push到远程master分支 git push origin :hotfixes/BJVEP933 # 删除远程仓库的hotfixes/BJVEP933分支 git push --tags # 把所有tag推送到远程仓库 git fetch # 获取所有远程分支(不更新本地分支,另需merge) git fetch --prune # 获取所有原创分支并清除服务器上已删掉的分支 git pull origin master # 获取远程分支master并merge到当前分支 git mv README README2 # 重命名文件README为README2 git reset --hard HEAD # 将当前版本重置为HEAD(通常用于merge失败回退) git rebase git branch -d hotfixes/BJVEP933 # 删除分支hotfixes/BJVEP933(本分支修改已合并到其他分支) git branch -D hotfixes/BJVEP933 # 强制删除分支hotfixes/BJVEP933 git ls-files # 列出git index包含的文件 git show-branch # 图示当前分支历史 git show-branch --all # 图示所有分支历史 git whatchanged # 显示提交历史对应的文件修改 git revert dfb02e6e4f2f7b573337763e5c0013802e392818 # 撤销提交dfb02e6e4f2f7b573337763e5c0013802e392818 git ls-tree HEAD # 内部命令:显示某个git对象 git rev-parse v2.0 # 内部命令:显示某个ref对于的SHA1 HASH git reflog # 显示所有提交,包括孤立节点 git show HEAD@{5} git show master@{yesterday} # 显示master分支昨天的状态 git log --pretty=format:'%h %s' --graph # 图示提交日志 git show HEAD~3 git show -s --pretty=raw 2be7fcb476 git stash # 暂存当前修改,将所有至为HEAD状态 git stash list # 查看所有暂存 git stash show -p stash@{0} # 参考第一次暂存 git stash apply stash@{0} # 应用第一次暂存 git grep "delete from" # 文件中搜索文本“delete from” git grep -e '#define' --and -e SORT_DIRENT git gc git fsck
上面只是作参考,更权威的东西在官网Git - Reference
git flow
A successful Git branching model » nvie.com
越靠近右边,越接近上线
从右到左分别为
master
分支:
-
永远保持稳定和可发布的状态。
-
每次发布一个新的版本时,都会从
develop
分支合并到master
分支。
hotfix
分支:
-
用于修复紧急问题。
-
从
master
分支创建,修复完成后合并回master
和develop
分支,并打上版本标签。 -
命名规范:
hotfix/hotfix-name
。
release
分支:
-
用于准备新版本的发布。
-
从
develop
分支创建,进行最后的测试和修复,然后合并回develop
和master
分支,并打上版本标签。 -
命名规范:
release/release-name
。
develop
分支:
-
用于集成所有的开发分支。
-
代表了最新的开发进度。
-
功能分支、发布分支和修复分支都从这里分支出去,最终合并回这里。
feature
分支:
-
用于开发新功能。
-
从
develop
分支创建,开发完成后合并回develop
分支。 -
命名规范:
feature/feature-name
。
简单来说
master:线上跑的代码就是master分支的代码
hotfix:热补丁分支,负责线上紧急问题的修复
release:预上线分支,在准备上线的时候,先把代码放在这个分支提供给测试人员做上线前的最后一次测试
develop:开发分支,所有人基于这个分支进行开发,并基于这个分支进行功能分支的拉取
feature:功能分支,每当要新开发一个新功能的时候,从develo拉取一个新功能的分支,开发完成之后再合并到develop分支
master和develop是常驻分支,期初这两个分支的内容是一样的
视频讲解 2:13-4:30
【教程】Gitflow介绍与使用经验分享 - 轩脉刃de刀光剑影哔哩哔哩bilibili
sourcetree
SourceTree 简化了开发者与代码仓库之间的 Git 操作方式,我们可以通过界面菜单很方便的处理 Git 操作,而不需要通过命令。
通过 SourceTree,我们可以管理所有的 Git 库,无论是远程还是本地的。SourceTree 支持 Bitbucket、GitHub 以及 Gitlab 等远程仓库。
是一个很好用的可视化git管理工具
博客:Git 管理工具 SourceTree 的使用(上手简单,不熟悉git命令的开发者必用)-CSDN博客
官网:Sourcetree | Free Git GUI for Mac and Windows