美橙建站怎么样,搜狗广告联盟,毕业设计网站建设选题依据,西安网站建设首选文章目录 Git协作冲突冲突的发生情况解决冲突如何处理冲突 1 分支1.1 什么是Git分支1.2 创建分支 2 切换分支2.1 指向分支2.2 暂存分支切换分支与未提交更改的处理使用 Stash 临时保存更改Stash 的工作原理#xff1a;场景设定使用 Git Stash 3 远程分支3.1 快进合并快进合并的… 文章目录 Git协作冲突冲突的发生情况解决冲突如何处理冲突 1 分支1.1 什么是Git分支1.2 创建分支 2 切换分支2.1 指向分支2.2 暂存分支切换分支与未提交更改的处理使用 Stash 临时保存更改Stash 的工作原理场景设定使用 Git Stash 3 远程分支3.1 快进合并快进合并的工作机制快进合并的场景非快进合并快进合并的影响 3.2 拉取git pull3.3 获取git fetchgit fetch vs. git pull具体使用示例 3.4 推送git push 4 分支的工作流程1. 主分支Main Branch2. 功能分支Feature Branches3. 发布分支Release Branches4. 修补分支Hotfix Branches5. 开发分支Development Branch4.1 主分支4.2 功能发布4.3 发布分支4.4 修补分支4.5 开发分支4.6 Git分支工作流程示例分支策略工作流程步骤详解1. **发现生产中的Bug**2. **创建Bug修复分支**3. **修复Bug并合并**4. **返回到功能分支**5. **同步开发分支的更改**6. **使用变基进行同步**7. **继续功能开发** 5 整合分支5.1 合并分支5.2 将分支变基 6 标签7 查看变更其他git statusgit log总结 Git协作
冲突
在版本控制系统中特别是在使用Git时冲突Conflict指的是当多个团队成员对同一个文件的相同部分进行更改并尝试合并这些更改时发生的问题。冲突通常出现在合并分支、重基rebase操作或应用补丁时因为这些操作涉及将一个分支的更改整合到另一个分支上。
冲突的发生情况
冲突发生的典型情况包括 编辑冲突 两个或更多开发者修改了同一个文件的同一部分。例如如果开发者A删除了一个函数而开发者B在同一函数中添加了一些新代码当这两个分支合并时Git无法自动决定哪个版本是正确的。 文件冲突 一个开发者修改了一个文件而另一个开发者删除了同一个文件或两个开发者重命名/移动了同一个文件但目标不同。
解决冲突
当冲突发生时Git会标记冲突的文件并在文件内容中插入特定的标记指示冲突的位置。这些标记分为以下几部分
开始冲突标记 此标记后跟的是当前分支的内容。分隔符 分隔当前分支内容和其他分支的内容。结束冲突标记 此标记后跟的是合并进来的分支的内容。
例如如果在两个分支上对同一文件的同一行进行了不同的更改Git无法自动合并文件将包含类似以下内容 HEAD
console.log(This is the version in the current branch.);console.log(This is the version in the branch being merged.);feature-branch如何处理冲突
解决冲突通常涉及以下步骤 识别冲突 使用 git status 查看哪些文件存在冲突。 手动编辑文件 打开冲突文件查看冲突标记并决定保留哪个版本的更改或者可能合并这两个版本的更改。 标记文件为已解决 解决完冲突后使用 git add file 命令将文件标记为已解决。这告诉Git您已经手动解决了这些冲突。 完成合并 一旦所有冲突都被解决并标记完成合并过程通常是通过 git commit 命令。通常Git会提供一个默认的合并提交消息确认即可。
处理冲突需要细致的注意力确保合并后的结果符合预期同时保持代码的功能和完整性。在团队环境中有效的沟通和代码审查可以大大减少冲突的发生。
1 分支
1.1 什么是Git分支
在处理不同任务的时候开不同的分支把不同的任务区别开 多个不同的分支可以合并成一个分支各个分支互不影响除非拉取新的更改 为每个任务创建分支是个值得采用的做法可以更好的追溯变更。
1.2 创建分支
创建新的分支不会更改存储库只是指出了提交。如下图所示使用 git branch 命令创建一个名为issue1的分支存储库将保持不变只是为当前提交添加了一个新指针。 2 切换分支
git checkout 命令可更新工作树中的文件以匹配存储在您希望切换到的分支中的版本。类似于切换目录或者工作区。
2.1 指向分支 HEAD 用于表示分支的当前快照。对于一个新的存储库在默认情况下Git 会将 HEAD 指向主分支。更改 HEAD 指向的位置将更新您的活动分支。 (代字号) 和 ^ (插入符号) 指向相对于特定提交的位置。这些符号与提交引用一起使用通常是 HEAD 或提交哈希(hash)。 ~ 指的是祖先 (多少代取决于~后的数字)。 HEAD~1 指的是提交的第一个父级。HEAD~2 指的是提交的第一个祖父级。 ^ 指的是合并提交的父级。 HEAD^1 指的是 HEAD 的第一个父级其中 head 是合并提交。HEAD^2 指的是 HEAD 的第一个祖父级其中 head 是合并提交。
合并提交中的提交可以有多个父项。 2.2 暂存分支
当您在使用Git进行版本控制时可能会遇到需要在多个分支之间切换的情况同时又希望保留未提交的更改。这时Git提供了一些策略来处理这些未提交的更改以便您可以无碍地在不同分支间进行工作。
切换分支与未提交更改的处理 基本行为 当您在工作树中有未提交的更改包括新文件、修改或删除的文件时这些更改可以被带到新分支上前提是不会与新分支的文件产生冲突。如果您提交了这些更改它们将仅存在于您切换到的新分支上。 冲突防止切换 如果存在冲突即当前分支的未提交更改与目标分支的文件内容不兼容Git不会允许您直接切换分支。这是为了防止潜在的代码丢失。
使用 Stash 临时保存更改
为了解决在分支间切换时带来的问题Git 提供了一个称为 stash 的功能允许您临时存储未提交的更改以便您可以清洁地切换到其他分支继续工作。
Stash 的工作原理 存储更改 使用 git stash 或 git stash push 命令将当前工作树中的更改保存起来这样您的工作树就回到了干净的状态如同刚刚克隆仓库后的状态。 git stash列出存储的更改 可以通过 git stash list 查看所有存储的更改条目。 git stash list恢复更改 当您需要恢复之前存储的更改时可以使用 git stash pop应用最近的更改并从stash列表中移除它或 git stash apply应用更改但保留在stash列表中。 git stash pop让我们通过一个具体的例子来说明如何使用 git stash 来管理工作区中未提交的更改使您能够在不同的分支之间灵活切换。 场景设定 假设您正在开发一个新功能在分支 feature-x 上工作。在您开发的过程中突然接到通知需要立刻解决主分支 main 上的一个紧急bug。 此时您的工作区有未提交的更改这些更改还不够稳定不能直接提交。同时您需要切换到 main 分支来修复bug。 使用 Git Stash 保存当前更改 在您的 feature-x 分支上使用以下命令将所有未提交的更改包括暂存和未暂存的存入stash git stash push -m WIP: Feature X adjustments这里的 -m 选项允许您为stash项添加一个描述性消息便于以后识别和恢复。 查看Stash列表 输入以下命令查看当前保存的stash项 git stash list这会显示所有stash项包括您刚刚添加的。 切换到主分支 清理了工作区后您现在可以安全地切换到 main 分支 git checkout main进行紧急修复 在 main 分支上进行必要的更改并提交。这可能包括测试、修改和提交修复 git add .
git commit -m Fix critical bug in main切换回功能分支 修复完成后切换回您的功能分支 git checkout feature-x恢复之前的工作 使用以下命令将之前stashed的更改重新应用到工作区 git stash pop这将应用最近的stash项并从stash列表中删除它。
3 远程分支
3.1 快进合并
在Git中快进合并fast-forward merge是一种特殊类型的合并它发生在当一条分支可以直接前进到另一条分支的末端时无需进行任何实际的合并操作。这种情况通常发生在没有新的并行提交影响这两个分支的情况下即当前分支的末端提交是要合并分支的基础上直接发展出来的提交。
快进合并的工作机制 简化的视图 当一个分支的所有提交都在另一个分支的直接历史线上时就可以进行快进合并。这意味着可以简单地将接收分支的指针HEAD前移到源分支的最新提交而不需要创建一个新的合并提交。 没有分支点 快进合并不会创建一个新的合并提交因为它仅仅涉及指针的移动。这样做保持了项目历史的线性和简洁。
快进合并的场景
假设您有两个分支main 和 feature。feature 分支从main分支分出来main分支在此期间没有新的提交而feature分支有若干提交。当你决定将feature分支合并回main分支时 操作 git checkout main
git merge feature结果 如果main分支在feature分出后没有新的提交Git会执行快进合并直接将main分支的HEAD指针移动到feature分支的最新提交。这样main分支现在包含了所有feature分支的更改。
非快进合并
相对于快进合并非快进合并发生在当目标分支自分支点以来有新的提交时即两个分支都有各自独立的提交。在这种情况下Git无法简单地进行指针前移因为这样会丢失目标分支上的更改。 操作 如果你想确保即使可以进行快进合并也要创建一个新的合并提交可以使用--no-ff选项 git merge --no-ff feature结果 这将强制Git创建一个新的合并提交即使是快进合并也不例外。这样做可以保留分支信息和合并历史。
快进合并的影响
快进合并的优点是保持了历史的清洁和线性但在某些情况下保留分支的合并历史非快进合并可能更有助于了解项目历史的结构和重要决策。选择使用哪种合并策略取决于团队的偏好和项目的特定需求。
3.2 拉取git pull
您可以使用 git pull 命令将远程存储库中的最新更改应用到本地存储库。
例如假设远程分支位于本地分支的上游。远程分支将包含本地分支的所有更改如下所示。 远程分支在本地分支的上游。
在这种情况下如果我们要将远程分支 (origin/main) 的合并应用到我们的本地分支 (main)这将是一个快进合并。 但是如果本地 main 分支中的更改不存在于远程 origin/main 分支中则拉取命令将执行合并且将创建将这些更改绑定在一起的合并提交。 如果本地分支与远程分支不同Git 必须在拉取之前合并和提交。
执行拉取时会在本地存储库中自动创建合并提交。如果存在冲突您将必须解决冲突并手动提交合并。
如果没有冲突提交将自动合并。 3.3 获取git fetch
只要没有冲突在执行拉取时来自远程分支的更改会自动合并到您当前的本地分支。如果您想获取远程的修改但又不想将它们合并到您当前的本地分支中您可以执行 git fetch 命令。
获取将从远程下载本地分支上尚不存在的更改。获取FETCH_HEAD ref 将跟踪从远程存储库中获取的更改。
当远程和本地分支都包含不同的后代时修订历史记录将如下所示
远程和本地分支具有不同 main 时的修订历史记录。
更改获取后您可以通过合并获取_HEAD 或执行拉取将这些更改应用到本地存储库。
合并后更改将应用于本地存储库。
一旦获取FETCH_HEAD合并修订历史记录将产生与git pull操作相同的结果。拉取是同时执行获取和合并操作。
git fetch vs. git pull git fetch 用途git fetch 仅仅从远程仓库下载到本地仓库中尚不存在的更改但不会自动合并或修改您的当前工作。结果执行 git fetch 后您的本地仓库将包含远程仓库的最新更改但这些更改不会影响您的任何工作分支除非您显式合并它们。修订历史FETCH_HEAD 是一个特殊的引用它指向刚刚从远程仓库获取的最新提交。 git pull 用途git pull 是 git fetch 和 git merge 的组合。它不仅下载最新的远程更改还会尝试将这些更改合并到当前分支中。结果如果合并成功没有冲突您的当前分支将自动更新以包括远程分支的更改。修订历史如果合并成功您的本地分支修订历史将包括这些远程更改。
具体使用示例
1使用 git fetch 检查远程更改
假设您正在本地的 master 分支上工作并想查看远程仓库如 origin中的更新但不立即合并这些更改
git fetch origin执行此命令后您可以使用以下命令检查远程分支的状态而不影响您的本地分支
git log --oneline master..origin/master这会显示从远程 master 分支获取的提交这些提交还没有被合并到您的本地 master 分支。
2 合并 FETCH_HEAD
如果您决定要将这些更改合并到您的本地分支可以使用
git merge FETCH_HEAD这会将从 git fetch 获取的更改合并到您当前的分支中。
3使用 git pull 直接更新和合并
如果您确定要立即获取并合并远程分支的更改可以直接使用
git pull origin master这条命令等同于先执行 git fetch origin master 然后执行 git merge origin/master。
3.4 推送git push
在将本地分支推送到远程存储库之前所有提交都可用。换句话说您可以按照自己的节奏在本地分支工作而不会影响其他团队成员。
当您将本地分支推送到远程时Git 将快进合并到目标存储库。
但是如果推送导致非快进合并Git 将拒绝您的推送以防止您覆盖以前的提交。在这种情况下您必须拉取最新的远程更改并再次推送。 4 分支的工作流程
在成功的Git分支模型中提到的五种分支类型每种都具有特定的作用和管理规则。这些分支类型协助团队在不同的开发阶段进行组织和管理确保软件开发流程的清晰性和效率。以下是对这些分支的概述和整理
1. 主分支Main Branch
别称: master 或 main用途: 包含生产环境中的代码始终保持稳定且可部署。特点: 通常用于合并其他分支的成果如新功能、修补或发布准备。不直接在此分支上进行日常工作。
2. 功能分支Feature Branches
别称: 主题分支用途: 用于开发新功能或实验每个分支通常源自主分支或开发分支并最终合并回去。特点: 提供了一个隔离的环境允许开发者在不影响主分支稳定性的情况下工作便于代码审查和管理。
3. 发布分支Release Branches
用途: 用于准备即将发布的版本。从开发分支如develop分出进行最后的测试和微调。特点: 主要处理bug修复、文档生成和其他发布任务。一旦版本准备就绪并确认可以发布发布分支将合并到主分支和开发分支中随后关闭。
4. 修补分支Hotfix Branches
用途: 快速修复生产环境中的紧急问题。这些分支从主分支分出并在问题解决后立即合并回主分支和开发分支。特点: 旨在迅速解决生产中的关键问题确保对正在进行的开发活动的干扰最小。
5. 开发分支Development Branch
别称: 集成分支通常命名为develop用途: 包含所有为下一版本准备好的功能是功能分支合并的目标。特点: 在发布周期的大部分时间内保持活跃用于集成即将发布的功能。在发布前通常会从中创建一个发布分支。
这些分支策略提供了清晰的结构框架帮助团队高效管理复杂的开发流程优化协作和交付速度。根据项目和组织的需求团队可以对这些策略进行调整以最适合自己的工作方式。 4.1 主分支
在存储库中进行第一次提交时默认情况下 Git 会自动创建一个主分支。随后的提交将在主分支下进行直到您决定创建并切换到另一个分支。
驻留在主分支的代码库是生产就绪的。当最新的提交准备好用于特定版本时它将被赋予一个发布标签。 4.2 功能发布
当您开始处理新功能或 bug 修复时您应该创建一个功能分支 (即主题分支)。功能分支通常是在开发分支之外创建的。在功能的整个开发生命周期中该主题分支可以驻留在您的本地机器中。
每当您准备好将变更集与开发分支合并时您将把这个分支推送到远程存储库。 4.3 发布分支
当您推出新版本时您会创建一个发布分支。发布分支可帮助您确保新功能的正常运行。
按照惯例在命名发布分支时以前缀release-开头。
通常当它接近生产就绪时您会在开发分支之外创建发布分支。
团队成员应仅解决此分支上的 bug 修复和与发布相关的问题。这允许其他团队成员继续将新功能推送到开发分支而不会中断发布的工作流程。
准备发布时将发布分支与主分支合并并为新创建的合并提交标记发布编号。
您还应该将发布分支与开发分支合并以便主分支和开发分支都可从发布分支接收最新的更改/bug 修复。
4.4 修补分支
当您需要快速向生产代码库添加关键修复时您可以在主分支之外创建一个修补分支。
按照惯例在命名修补分支时以前缀hotfix-开头。
修补分支的优点是它允许您快速发布补丁并将更改与主分支合并而无需等待下一个版本。
修补分支也应该与开发分支合并。
4.5 开发分支
您的团队应该始终保持开发分支 (即集成分支) 的稳定。您的团队从这个分支创建新的分支它可以在生产环境中运行。持续集成工具例如 Jenkins 可以做到这一点。
当一些更改需要合并到开发分支时创建一个功能/分支来处理通常是个好主意。
4.6 Git分支工作流程示例
在这个Git分支策略工作流程示例中我们通过处理一个实际场景来阐明如何在开发新功能的同时快速响应并修复生产中的bug。这种分支策略有效地结合了开发/集成分支和功能/主题分支的使用确保开发流程的连续性和灵活性。
分支策略工作流程步骤详解
1. 发现生产中的Bug
在开发新功能的同时生产环境中出现了一个bug。为了不干扰当前的功能开发需要创建一个专门的bug修复分支。
2. 创建Bug修复分支
从开发分支通常是develop分出一个新的分支来专门处理这个bug。这保证了bug修复工作与功能开发工作的隔离。
3. 修复Bug并合并
在这个新的bug修复分支上进行工作一旦完成修复就将这个分支合并回开发分支。这一步确保所有的bug修复都会反映到主要的开发线上。 4. 返回到功能分支
修复完bug后切换回原先的功能分支继续新功能的开发。 5. 同步开发分支的更改
开发新功能时您可能需要刚刚合并到开发分支上的修复。这需要您将开发分支的更改包括bug修复整合到您的功能分支上。您可以通过以下两种方式来实现 合并Merge将开发分支合并到您的功能分支这将保留两个分支的历史。变基Rebase将您的功能分支变基到最新的开发分支上。这使得历史更为线性好像您是在最新的开发状态基础上开始添加新功能。
6. 使用变基进行同步
选择使用变基来更新您的功能分支这样您的分支看起来就像是直接基于最新的开发分支开始的。这样可以使项目历史更清晰也更易于理解。
7. 继续功能开发
完成变基后您的功能分支现在包含了必要的bug修复。您可以继续开发新功能确保所依赖的代码是最新且稳定的。
5 整合分支
合并方法保留合并分支的所有更改和历史记录。多次合并后修订历史记录可能会变得复杂。变基方法维护一个干净的修订历史记录因为合并的提交会附加在目标分支的末尾。与合并的方法相比冲突可能更频繁地发生。
为了使您的修订历史记录保持简洁您可以在将功能分支合并到开发分支之前将功能分支变基。这会导致快进合并而不会创建额外的合并提交。
5.1 合并分支
您可以使用 git merge 指令来将多个分支集成。
考虑下面的情况。有两个分支一个bugfix分支其中有一些来自main分支的提交。 在这种情况下将“bugfix“合并回“主要“分支并不是什么大问题。那是因为自从创建“bugfix”分支以来“主要“分支没有改变。Git 将通过将“主要“分支位置移动到“bugfix“分支的最新位置来合并它。这种合并称为“快进“。 然而在下面的示例中自从bugfix分支出来后main分支已经更新了几次。在这两个分支上执行合并时必须组合来自bugfix和main分支的更改。 对于这种合并创建一个“合并提交“并将“主要“位置更新为新创建的合并提交。 即使快进合并是可能的您仍然可以明确地强制它在没有快进合并的情况下进行合并。 如上所示非快进合并保留了bugfix分支。这让您更清楚地了解功能分支bugfix。您可以轻松找到功能分支的开始或结束位置并跟踪对功能分支所做的更改。
5.2 将分支变基
要获得更清晰的修订历史记录您可以使用 git rebase 命令来整合您的分支。
假设我们有两个具有非快进合并场景的分支。 变基将导致分支历史记录看起来类似于下面的示例。 当您将bugfix分支变基到主分支时来自bugfix分支的提交将被重播并附加到主分支的末尾。结果是bugfix分支历史记录中的单个简单提交串流。
如果在附加提交时发生冲突Git 会要求您解决冲突然后再继续对其他提交进行变基。 变基不会移动main的位置。在任何情况下您都可以在变基后进行快进或从bugfix到main的干净合并。 6 标签
Git 标签标记并标记历史记录中的特定提交。标签通常用于指示发布版本发布名称 (即 v1.0) 是标签的名称。
Git 标签有两种类型
轻量标签附注标签
轻量标签类似于不会改变的分支。它只是直接指向历史记录中的特定提交。轻量标签主要在您的本地工作区中暂时使用。
附注标签是校验和的通常在计划标记重要提交时使用。您可以添加消息、签名、日期以及标记者的姓名和电子邮件。 7 查看变更
1git diff
用途git diff 命令用于显示工作目录中未暂存的文件修改和暂存的文件修改之间的差异或比较两个提交之间的差异。
功能详解 未暂存的变更git diff 默认显示工作目录中所有未暂存的变更。 git diff暂存的变更使用 git diff --staged 或 git diff --cached 查看已暂存的变更。 git diff --staged两个提交之间的差异指定两个提交的哈希值来查看它们之间的差异。 git diff commit1 commit22git show
用途git show 命令用于显示一个对象通常是提交的类型、大小、内容等信息。
功能详解 查看特定提交显示单个提交的详细信息包括提交的差异和元数据。 git show [commit-hash]3git log
用途git log 命令用于查看提交历史记录可以与不同的选项组合使用以查看特定的历史变更。
功能详解 查看特定文件的提交历史显示指定文件的提交历史包括相关的更改。 git log -p [filename]图形化显示分支合并历史使用图形选项查看更直观的分支历史。 git log --graph --oneline --all4git blame
用途git blame 命令用于显示每一行文件的最后修改者信息非常有用于追踪特定行的变更历史。
功能详解 查看文件修改者逐行显示文件的修改记录包括提交哈希和作者。 git blame [filename]其他
git status 和 git log 是两个基本的 Git 命令它们在日常 Git 使用中扮演着不同的角色。这两个命令提供的信息有着根本的区别分别关注当前工作区的状态和项目的提交历史。
git status
用途git status 命令用于显示 Git 工作目录和暂存区的状态。它是诊断和解决代码中状态相关问题的首选工具。
主要功能
显示哪些文件处于修改状态已修改但未暂存。显示哪些文件已暂存待提交已修改并已暂存。显示当前工作目录与指定分支通常是当前分支的差异。提示如何暂存或取消暂存更改以及如何回滚对文件的修改。提供当前分支和其上游分支的同步状态前提是设置了上游分支。
输出示例
On branch main
Your branch is up to date with origin/main.Changes to be committed:(use git restore --staged file... to unstage)new file: example.txtChanges not staged for commit:(use git add file... to update what will be committed)(use git restore file... to discard changes in working directory)modified: readme.mdUntracked files:(use git add file... to include in what will be committed)sample.txtgit log
用途git log 命令用于显示当前分支的提交历史。它可以帮助开发者回顾和审查项目的发展过程。
主要功能
显示提交历史包括提交的哈希值、作者、日期和提交消息。可以通过各种选项来定制显示的日志如日期范围、作者、文件更改历史等。支持图形化显示历史通过--graph选项展示分支合并历史。
输出示例
commit fa3e98197e714dbf123681f6927a05538db6aa56 (HEAD - main, origin/main, origin/HEAD)
Author: John Doe johnexample.com
Date: Wed Sep 15 14:56:29 2021 0200Add new featurecommit aea57694cd1bfeda98234aeccc8ae202b58db2b4
Author: Jane Smith janeexample.com
Date: Tue Sep 14 12:48:53 2021 0200Update README.md总结
git status 用于查看工作目录和暂存区的当前状态是了解当前工作进度和状态的最直接的工具。git log 用于查看提交历史帮助你了解项目的版本历史和过去的开发活动。
这两个命令在日常的 Git 使用中非常关键为开发者提供了关于项目状态和历史的重要信息。
