企业官网建设流程全解析

Git从入门到精通原理、实战与企业级协作全攻略文章目录Git从入门到精通原理、实战与企业级协作全攻略Git从入门到精通原理、实战与企业级协作全攻略前言为什么每个开发者都必须掌握Git第一部分Git初识与安装1.1 什么是版本控制器1.2 为什么Git是王者1.3 注意事项Git能跟踪什么1.4 Git安装指南Linux (CentOS/RedHat)Linux (Ubuntu/Debian)WindowsMac第二部分Git核心原理与基本操作2.1 初次运行前的配置你是谁2.2 创建仓库git init2.3 核心概念工作区、暂存区、版本库2.4 核心操作添加与提交添加文件到暂存区git add提交到版本库git commit查看提交历史git log2.5 深入理解探索.git目录2.6 查看状态与差异git status和git diff2.7 强大的版本回退git reset2.8 撤销修改2.9 删除文件第三部分分支管理——Git的杀手锏3.1 什么是分支3.2 分支的基本操作3.3 合并冲突Merge Conflict3.4 合并模式Fast-forward vs. 普通模式3.5 实战技巧Bug分支与Stash3.6 强制删除未合并的分支第四部分远程仓库——开启多人协作4.1 为什么需要远程仓库4.2 准备工作添加SSH Key4.3 克隆远程仓库git clone4.4 推送至远程git push4.5 拉取远程更新git pull4.6 远程协作的常见冲突第五部分标签管理——给你的版本命名5.1 什么是标签Tag5.2 基本操作第六部分企业级开发模型——Git Flow6.1 核心分支6.2 辅助分支临时分支用完即删6.3 环境对应关系6.4 Git Flow实战场景场景一开发一个新功能“订单管理”场景二发布一个新版本场景三紧急修复线上Bug第七部分高级配置与最佳实践7.1 忽略特殊文件.gitignore7.2 给命令配置别名7.3 最佳实践总结结语总结好的这是一份根据您提供的PDF内容整理的、详尽且系统化的Git学习笔记。这份笔记涵盖了从基础概念到企业级实战的方方面面非常适合作为一篇深度博客文章。由于原始材料内容丰富但距离“10万字”仍有巨大差距我将在此结构基础上为您扩充大量解释、类比、最佳实践和常见问题解答使其更加丰满。您可以将其作为核心骨架再结合自己的实践和理解不断添砖加瓦。Git从入门到精通原理、实战与企业级协作全攻略前言为什么每个开发者都必须掌握Git在软件开发的漫漫长路上版本控制是永恒的主题。回想一下你是否曾经历过这样的场景毕业论文从论文_v1.docx、论文_v2.docx最终变成了论文_最终版_v3_打死也不改了.docx项目代码因为一次错误的修改导致系统崩溃却因为没有备份而无法恢复团队协作时代码被同事覆盖辛辛苦苦写了几天的功能瞬间消失这些问题的根源在于缺乏有效的版本管理。而Git就是解决这一切问题的终极武器。Git是目前世界上最先进的分布式版本控制系统。它由Linux之父Linus Torvalds为了管理Linux内核源码而开发如今已成为全球软件开发者的标配。无论是Google、Facebook、阿里、腾讯还是你身边任何一个程序员几乎都在使用Git。本文将带你从零开始深入理解Git的原理、掌握核心操作、精通分支管理并最终体验企业级的多人协作开发与Git Flow工作流。无论你是刚入行的新手还是希望巩固知识的资深工程师这篇万字长文都值得你收藏。第一部分Git初识与安装1.1 什么是版本控制器版本控制器Version Control System, VCS是一种能记录一个或若干文件内容变化以便将来查阅特定版本修订情况的系统。简单来说它就是一台“时间机器”可以让你回溯历史查看文件每一次修改的记录知道谁、什么时候、改了什么。版本回退如果新改的代码出了错可以一键回到之前的任何一个正确版本。协同工作多人可以同时修改同一个文件系统会自动合并或提示冲突。1.2 为什么Git是王者在Git出现之前有CVS、SVN等集中式版本控制系统。它们有一个中央服务器所有用户都需要从服务器获取最新版本修改后再提交回服务器。这种模式的缺点是如果没有网络或者中央服务器宕机所有人都无法工作。Git作为分布式版本控制系统每个开发者的电脑上都有一个完整的版本库。这意味着离线可用即使没有网络你也能进行提交、查看历史、比较差异等操作。安全可靠任何一个人的电脑坏了只要从其他人那里克隆一份就能恢复所有数据。极其高效绝大多数操作都在本地完成速度飞快。创建分支、合并分支几乎瞬间完成。1.3 注意事项Git能跟踪什么Git最主要的能力是跟踪文本文件的每次改动比如源代码.c, .java, .py、配置文件、网页文件.html, .css, .js等。它会精确地记录哪一行加了什么哪一行删了什么。对于图片、视频、可执行文件等二进制文件Git虽然可以管理但无法像文本文件那样逐行显示差异只能知道文件大小改变了。因此不建议将大型二进制文件频繁提交到Git中。1.4 Git安装指南Git支持所有主流操作系统。Linux (CentOS/RedHat)# 安装sudoyum-yinstallgit# 查看版本git--versionLinux (Ubuntu/Debian)# 安装sudoapt-getinstallgit-y# 查看版本git--versionWindows访问Git官网https://git-scm.com/download/win下载.exe安装包一路默认选项安装即可。安装完成后在开始菜单中找到“Git Bash”这是一个模拟的Linux终端可以执行所有Git命令。Mac方法一安装Xcode Command Line Tools其中包含Git。方法二从Git官网下载安装包。第二部分Git核心原理与基本操作2.1 初次运行前的配置你是谁Git在提交代码时需要知道你的身份。这个信息会永久记录在你的每一次提交中。使用--global选项表示这台机器上的所有仓库都使用这个配置。# 设置用户名gitconfig--globaluser.nameYour Name# 设置邮箱gitconfig--globaluser.emailyour_emailexample.com# 查看所有配置gitconfig-l# 删除配置gitconfig--global--unsetuser.namegitconfig--global--unsetuser.email2.2 创建仓库git init仓库Repository就是Git进行版本控制的一个目录。你需要告诉Git哪个目录需要被管理。# 进入你的项目目录cd/path/to/your/project# 初始化Git仓库gitinit执行后当前目录下会多出一个.git的隐藏文件夹。千万不要手动修改或删除这个文件夹里的任何东西它是Git的“大脑”存储着所有的历史记录、配置信息等。2.3 核心概念工作区、暂存区、版本库这是Git最核心、也最容易让初学者困惑的三个概念。理解它们你就理解了Git的精髓。工作区 (Working Directory)就是你电脑上能看到的项目目录比如/home/hyb/gitcode。你在这里编辑、修改、新增文件。暂存区 (Stage/Index)存放在.git/index文件中。它像一个临时的“购物车”。你用git add命令就是把你工作区中的修改放到购物车里。版本库 (Repository)就是.git目录。当你执行git commit命令时就是把暂存区购物车里的所有内容一次性打包成一个快照永久保存到版本库中。一句话总结你在工作区干活干完一批就用git add放进暂存区等积累到一定量或用git commit“拍照存档”到版本库。2.4 核心操作添加与提交添加文件到暂存区git add# 添加单个文件gitaddReadMe# 添加多个文件gitaddfile1 file2 file3# 添加当前目录下所有改动gitadd.提交到版本库git commit# 提交暂存区所有内容-m后面跟上本次提交的说明gitcommit-mcommit my first file# 提交指定文件gitcommit file1 file2-mupdate two files重要提示-m参数后面的说明信息绝对不能省略它是对你这次修改的描述方便你和团队成员日后查看历史。好的提交信息应该清晰、准确如fix: 修复了登录页面的空指针异常或feat: 新增了用户个人资料编辑功能。查看提交历史git log# 查看详细历史gitlog# 查看简洁版历史一行一个提交gitlog--prettyoneline# 查看图形化的分支历史gitlog--graph--prettyoneline --abbrev-commit你会看到一串长长的十六进制数字如23807c536969cd886c4fb624b997ca575756eed6这就是commit id (版本号)。它是Git用SHA-1算法根据提交内容计算出来的全球唯一。2.5 深入理解探索.git目录让我们揭开.git的神秘面纱看看里面到底有什么。ls-a.git/主要文件/目录index这就是暂存区文件。HEAD当前指针它指向我们当前正在工作的分支。cat.git/HEAD# 输出: ref: refs/heads/masterrefs/heads/mastermaster分支文件里面保存着该分支最新的一次commit id。objects/对象库Git保存的所有文件内容和提交信息都以加密后的形式存在这里。你可以用git cat-file -p commit-id来查看其内容。通过观察.git目录的变化你可以“眼见为实”地理解Git的内部运作。2.6 查看状态与差异git status和git diffgit status最常用的命令。它会告诉你当前工作区、暂存区相对于版本库有哪些改动。git diff查看具体的差异。git diff比较工作区与暂存区的差异。git diff HEAD -- [file]比较工作区与最新版本库的差异。2.7 强大的版本回退git reset版本回退是Git的核心功能之一。当你想回到过去的某个版本时git reset就是你的“后悔药”。语法git reset [--soft | --mixed | --hard] [HEAD]--mixed默认模式重置暂存区使其与指定的提交一致但工作区保持不变。你之前git add但没commit的内容会被移出暂存区。--soft只移动HEAD指针改变当前分支指向的提交。工作区和暂存区的内容都不变。相当于你只是把“存档点”挪到了过去但购物车里的东西和新写的代码都还在。--hard彻底回滚。将暂存区和工作区都重置为指定提交的内容。这个操作会丢失你所有未提交的本地修改使用前务必三思HEAD的用法HEAD当前版本HEAD^上一个版本HEAD^^上上个版本HEAD~100往上100个版本。示例从version3回退到version2gitreset--hardHEAD^后悔了想回到version3只要你知道version3的commit id就可以“穿越”回去。gitreset--hardd95c13f救命稻草git reflog如果你记不住commit id了git reflog记录了你在本地仓库的每一次操作命令从中可以找到你“穿越”前的commit id。2.8 撤销修改情况一工作区的修改还没add直接删除新增的代码或者使用gitcheckout --[file]这条命令会把工作区的文件恢复到最近一次git add或git commit时的状态。情况二已经add但还没commit先用git reset HEAD [file]把暂存区的修改回退到工作区再用git checkout -- [file]丢弃工作区的修改。情况三已经commit但还没推送到远程使用版本回退git reset --hard HEAD^即可。2.9 删除文件如果确实要从版本库中删除文件# 1. 删除工作区和暂存区的文件gitrmfile5# 2. 提交这个删除操作gitcommit-mdeleted file5如果不小心删错了比如用rm file5可以用git checkout -- file5恢复。第三部分分支管理——Git的杀手锏3.1 什么是分支分支是Git最强大的功能没有之一。我们可以把分支理解为平行宇宙。你在主宇宙master分支里安心地工作。当你有一个新想法或新功能要开发时你创建一个新分支dev分支。在这个新宇宙里你随意折腾甚至搞砸了都没关系。当新功能开发完成并且测试无误后你把这个新宇宙合并到主宇宙。你的主宇宙就拥有了新功能而整个过程对主宇宙毫无影响。Git的分支是极其轻量级的。创建和切换分支几乎是瞬间完成因为Git只是创建了一个指向不同提交的指针而已。3.2 分支的基本操作查看分支git branch*表示当前所在分支创建分支git branch dev切换分支git checkout dev或git switch dev创建并切换git checkout -b dev或git switch -c dev合并分支首先切换回master分支然后将dev分支合并过来。gitcheckout mastergitmerge dev删除分支git branch -d dev-d表示delete3.3 合并冲突Merge Conflict当两个分支对同一个文件的同一行代码进行了不同的修改时Git就无法自动合并了这就产生了冲突。Git会修改冲突文件在其中标记出冲突区域 HEAD 这是master分支的修改 这是dev1分支的修改 dev1你需要手动编辑这个文件决定保留哪个版本或者整合两者删除Git添加的标记符号。最后git add和git commit完成合并。3.4 合并模式Fast-forward vs. 普通模式Fast-forward快进模式当合并分支时如果master分支没有新的提交Git只需要简单地把master指针向前移动到dev的位置即可。这种模式不会创建新的commit。缺点是删除dev分支后会丢失分支的历史信息。普通模式使用git merge --no-ff -m merge message dev强制禁用Fast-forward。这样Git会创建一个新的commit来记录这次合并。从历史上可以清楚地看到曾经有过一个分支。在实际工作中推荐使用普通模式。3.5 实战技巧Bug分支与Stash想象一个场景你正在dev分支上开发一个新功能代码写到一半还没完成不能提交。突然线上生产环境master分支发现了一个紧急Bug需要马上修复。怎么办这时git stash命令就是你的救星。它可以把当前工作现场工作区和暂存区的所有修改“储藏”起来让你的工作区变得干净。# 1. 储藏工作现场gitstash# 2. 切换到master创建修复bug的分支gitcheckout mastergitcheckout-bfix_bug# 3. 修复bug然后提交、合并、删除fix_bug分支...# 4. 切换回dev分支恢复工作现场gitcheckout devgitstash pop# 恢复并删除stash记录# 或者 git stash apply # 恢复但不删除stash记录3.6 强制删除未合并的分支如果一个分支上的代码还没被合并而你决定废弃它git branch -d会失败。此时需要使用-D选项强制删除。gitbranch-Dfeature_branch第四部分远程仓库——开启多人协作4.1 为什么需要远程仓库本地仓库是你个人电脑上的版本库。为了让团队协作我们需要一个大家都能访问到的“公共服务器”。这个服务器上的仓库就是远程仓库。GitHub、Gitee码云、GitLab等都是提供Git仓库托管服务的平台。4.2 准备工作添加SSH Key为了安全地连接远程仓库免密推送通常使用SSH协议。生成SSH Key在命令行中输入ssh-keygen-trsa-Cyour_emailexample.com一路回车会在用户目录的.ssh文件夹下生成id_rsa私钥和id_rsa.pub公钥。添加公钥到远程仓库登录Gitee/GitHub在个人设置中找到“SSH公钥”将id_rsa.pub文件的内容全部复制粘贴进去并保存。4.3 克隆远程仓库git clone当你加入一个新项目第一步就是把远程仓库完整地复制到你的电脑上。gitclone gitgitee.com:username/repository.git这个命令会做三件事下载远程仓库的所有数据。在本地创建一个.git目录。检出checkout默认分支通常是master的所有文件到工作区。克隆完成后Git会自动将本地master分支和远程的master分支关联起来并将远程仓库默认命名为origin。4.4 推送至远程git push当你在本地完成了某次提交想分享给团队时就需要推送到远程仓库。# 将本地的master分支推送到远程的origin仓库的master分支gitpush origin master# 推送本地dev分支到远程如果远程没有会自动创建gitpush origin dev4.5 拉取远程更新git pull当你的同事推送了新的代码你需要把它同步到本地。# 从远程origin仓库拉取master分支的更新并合并到当前分支gitpull origin mastergit pull实际上是git fetch从远程下载最新数据和git merge合并到本地分支两个命令的合并。更安全的做法是先用git fetch origin看看别人改了啥再用git merge或git diff检查后再合并。4.6 远程协作的常见冲突当你git push时如果远程分支有新的提交而你的本地分支没有推送就会被拒绝。此时你需要先git pull在本地解决冲突如果有再重新推送。多人协作的标准流程git add .git commit -m xxx在本地完成提交。git push origin branch-name尝试推送。如果失败说明远程有更新执行git pull origin branch-name。如果git pull提示有冲突手动解决冲突然后git add .和git commit -m fix conflict。再次git push origin branch-name成功第五部分标签管理——给你的版本命名5.1 什么是标签Tag标签就是给某次有里程碑意义的提交起一个“别名”。相比于一串无规律的commit idv1.0、v2.0.1这样的标签更人性化。5.2 基本操作# 切换到需要打标签的分支gitcheckout master# 给最新的一次提交打标签gittag v1.0# 给历史某次提交打标签gittag v0.9[commit-id]# 查看所有标签gittag# 查看标签详细信息gitshow v1.0# 创建带有说明的标签gittag-av1.0-mRelease version 1.0[commit-id]# 删除本地标签gittag-dv1.0# 推送单个标签到远程gitpush origin v1.0# 推送所有本地标签到远程gitpush origin--tags# 删除远程标签先删本地再删远程gittag-dv1.0gitpush origin :refs/tags/v1.0第六部分企业级开发模型——Git Flow在实际的企业开发中不会只有master和dev两个分支。为了应对复杂的开发、测试、发布和紧急修复场景业界总结了成熟的分支管理模型其中最著名的就是Git Flow。6.1 核心分支master主分支只读、唯一。任何时候master分支上的代码都是可随时部署到生产环境的稳定版本。通常由release分支或hotfix分支合并而来。每次合并到master都应该打一个对应版本的标签tag。develop开发分支只读、唯一。整合了所有已完成开发的功能的最新代码。是所有feature分支的“上游”。开发人员完成功能后合并回develop。对应开发环境。6.2 辅助分支临时分支用完即删feature/*功能分支来源从develop分支创建。命名feature/username_YYYYMMDD_feature-name。用途开发一个新功能。开发者可以在这个分支上随意提交。去向开发完成后合并回develop分支。release/*预发布分支来源当develop分支上的功能已经满足一次发布的要求时从develop分支创建。命名release/版本号_发布日期。用途冻结新功能只允许修复Bug。在此分支上进行最后的测试测试环境、预发布环境。这个分支的存在可以让开发团队在develop分支上继续开发下一个版本的功能互不干扰。去向测试通过后合并到master分支并打上标签同时合并回develop以确保修复的Bug也被同步。hotfix/*热修复分支来源当线上生产环境master分支发现紧急Bug时从master分支创建。命名hotfix/username_YYYYMMDD_hotfix-name。用途紧急修复线上问题。去向修复并测试验证后合并到master分支并打上新的标签同时必须合并回develop和当前的release分支如果存在确保修复不会在后续版本中再次出现。6.3 环境对应关系开发环境Dev部署develop分支。测试环境Test部署release/*分支。预发布环境Staging部署从release/*分支构建的、与生产环境配置最接近的版本。生产环境Production部署master分支上的某个标签如v1.2.0。6.4 Git Flow实战场景场景一开发一个新功能“订单管理”开发人员从最新的develop分支创建feature/hyb_order_20231012。在该分支上完成代码编写和自测。提交Pull Request (PR)或Merge Request (MR)请求合并到develop。代码审查通过后合并到develop。场景二发布一个新版本项目经理或技术负责人从develop分支创建release/v1.1_20231101。部署release/v1.1_20231101到测试环境测试人员开始测试。测试发现Bug开发人员在release/v1.1_20231101上修复而非develop。修复后再次测试直到通过。测试通过后将release/v1.1_20231101合并到master并在master上打标签v1.1。同时将release/v1.1_20231101合并回develop同步修复内容。删除release/v1.1_20231101分支。场景三紧急修复线上Bug线上出现严重Bug从当前线上的标签如v1.0对应的master分支创建hotfix/critical_bug_fix。快速修复Bug并本地验证。合并到master并打上新的标签v1.0.1立即部署上线。同时将hotfix/critical_bug_fix合并回develop和当前的release分支。删除hotfix/critical_bug_fix分支。第七部分高级配置与最佳实践7.1 忽略特殊文件.gitignore在项目中总有一些文件我们不想提交到Git仓库比如编译产生的.o、.class文件本地IDE的配置文件.idea/,.vscode/或者包含数据库密码的config.ini。创建一个名为.gitignore的文件写入要忽略的规则# 忽略所有以 .o 或 .so 结尾的文件 *.o *.so # 忽略所有以 ~ 结尾的临时文件 *~ # 但特别指定要跟踪 lib.so !lib.so # 忽略 build/ 文件夹下的所有内容 build/ # 忽略隐藏文件 .* # 但不忽略 .gitignore 文件本身 !.gitignore如果某个文件已经被.gitignore忽略了但你仍想强制添加它可以使用-f参数git add -f my_ignored_file。或者用git check-ignore命令检查是哪个规则忽略了它。7.2 给命令配置别名嫌命令太长可以给它们起个外号。gitconfig--globalalias.st statusgitconfig--globalalias.co checkoutgitconfig--globalalias.br branchgitconfig--globalalias.cm commitgitconfig--globalalias.lglog --graph --prettyoneline --abbrev-commit配置后git st就等同于git status了。7.3 最佳实践总结提交要早推送要勤。频繁地做git commit本地可以保存你的工作进度。功能完成后及时git push与团队同步。写有意义的提交信息。git commit -m fix bug是最糟糕的提交信息。好的信息应该是fix: 修复了用户登录时验证码不刷新的问题。每次推送前先git pull。这能最大程度避免不必要的合并冲突。绝不在master分支上直接修改。始终通过feature/release/hotfix分支来间接修改master。利用.gitignore保持仓库干净。不要把IDE的配置、编译产物等无关文件提交进去。在合并分支前确保本地分支是最新的。在git merge之前先git checkout到目标分支git pull一下。慎重使用--hard。在你还没有把代码push到远程之前git reset --hard会无情地丢弃所有未提交的修改。结语从个人开发到万人协作Git都是你不可或缺的伙伴。本文涵盖了从Git的基本原理、核心命令、分支管理到企业级Git Flow模型的全部内容。但请记住Git是一个工具它的强大在于它的灵活性。纸上得来终觉浅绝知此事要躬行。建议你亲自动手在自己的电脑上创建一个测试项目反复练习add、commit、reset、checkout、branch、merge等命令。注册一个Gitee或GitHub账号尝试clone、push、pull。找一个小伙伴一起模拟多人协作亲手解决一次合并冲突。在一个真实项目中实践Git Flow分支模型。当你能熟练地在不同分支间自由穿梭在复杂的合并冲突中游刃有余并把Git Flow内化为团队的工作流时你不仅掌握了一个工具更拥有了现代软件工程的核心协作能力。希望这篇笔记能成为你Git学习路上的忠实伙伴。Happy Gitting!总结这篇文章是作者搜集大量面经和资料这里出来的。感谢你的支持作者wkm是一名中国矿业大学(北京) 大一的新生希望得到你的关注如果可以的话记得一键三联