git工作流程(阮一峰完整总结版本各流程变化且有独到见解)
git 开发流程
git 开发流程1. 创建新的仓库。
在开始一个新的项目时，首先需要创建一个新的 git 仓库。
可以通过在本地新建一个文件夹并在其中运行 git init 命令来创建一个新的仓库。
也可以通过在远程仓库托管服务（如 GitHub、GitLab 等）上创建一个新的仓库来实现。
2. 添加和提交文件。
在项目进行过程中，需要不断地向仓库中添加新的文件或修改已有的文件。
可以使用 git add 命令将文件添加到暂存区，然后使用 git commit 命令将暂存区中的文件提交到仓库中。
提交时可以附上一条清晰明了的提交信息，以便后续版本回滚和代码审查。
3. 分支管理。
git 的分支管理功能非常强大，可以让开发人员在不影响主线代码的情况下进行并行开发。
可以使用 git branch 命令创建新的分支，使用 git checkout 命令切换分支，使用 git merge 命令合并分支等。
在团队协作中，合理的分支管理可以极大地提高开发效率。
4. 版本回滚。
在开发过程中，可能会出现一些错误或者不符合预期的情况。
这时就需要进行版本回滚操作。
可以使用 git log 命令查看提交历史，找到需要回滚到的版本号，然后使用 git reset 命令回滚到指定版本。
同时，也可以使用 git revert 命令创建一个新的提交来撤销之前的提交。
5. 团队协作。
git 作为一个分布式版本控制系统，非常适合团队协作。
团队成员可以通过远程仓库来共享代码，通过分支管理来并行开发，通过提交信息和代码审查来进行沟通和交流。
同时，也可以通过 git pull 和 git push 命令来同步远程仓库和本地仓库的代码。
6. 版本标签。
在项目中的一些重要的节点，比如发布版本、里程碑等，可以使用 git tag 命令来创建一个版本标签。
版本标签可以帮助开发人员更好地管理和跟踪版本，同时也可以方便地进行版本发布和回滚操作。
7. 持续集成。
git 与持续集成工具（如 Jenkins、Travis CI 等）结合使用可以实现自动化构建、自动化测试和自动化部署等功能。
简述git工作流程
简述git工作流程Git是一个版本控制系统，可以跟踪文件的更改和历史记录，同时可以协调多人在同一项目中的工作。
Git的工作流程可以分为本地工作、暂存区和仓库三个部分。
本地工作区是指开发者在本地计算机上进行的文件编辑和修改。
这些更改只在本地生效，不会影响到其他开发者或共享仓库。
开发者可以根据自己的需求进行修改、新增或删除文件。
暂存区是介于本地工作区和仓库之间的一个中间状态。
开发者可以将本地工作区中的更改提交到暂存区，但是这些更改并不会立即影响到仓库。
暂存区可以使开发者更好地掌控自己的更改，可以选择性地提交更改到仓库。
仓库是指包含所有历史版本和更改记录的中央存储库。
当开发者提交更改到仓库时，所有开发者都可以访问最新的版本。
开发者可以在仓库中查看历史记录、比较不同版本之间的差异、撤销更改等操作。
Git的工作流程可以分为以下几个步骤：1. 在本地工作区进行文件修改和编辑；2. 将更改提交到暂存区，使用“git add”命令；3. 将更改提交到仓库，使用“git commit”命令；4. 将本地工作区的更改推送到远程仓库，使用“git push”命令；5. 从远程仓库拉取最新的版本，使用“git pull”命令；6. 查看历史记录和版本信息，使用“git log”命令。
以上是Git的基本工作流程，但在实际开发中，可能会有多人协作、分支管理等复杂情况。
因此，需要根据具体情况进行相应的配置和管理。
例如，多人协作时，可以创建多个分支，每个开发者在自己的分支上进行工作，并定期将更改合并到主分支上。
这样可以避免不同开发者之间的冲突和误操作。
在Git中还有一些高级操作，如Git stash、Git merge、Git rebase等，可以帮助开发者更好地管理和掌控自己的代码。
但是这些操作需要一定的技术和经验，需要开发者不断学习和实践。
Git是一个强大的版本控制系统，可以帮助开发者更好地管理和协作代码。
了解Git的基本工作流程，可以使开发者更加高效地进行开发和管理。
常用 Git 命令清单 - 阮一峰的网络日志
三、增加/删除文件
# 添加指定文件到暂存区 $ git add [file1] [file2] ... # 添加指定目录到暂存区，包括子目录 $ git add [dir] # 添加当前目录的所有文件到暂存区 $ git add . # 添加每个变化前，都会要求确认 # 对于同一个文件的多处变化，可以实现分次提交 $ git add ‐p # 删除工作区文件，并且将这次删除放入暂存区 $ git rm [file1] [file2] ... # 停止追踪指定文件，但该文件会保留在工作区 $ git rm ‐‐cached [file] # 改名文件，并且将这个改名放入暂存区 $ git mv [file‐original] [file‐renamed]
十、其他
# 生成一个可供发布的压缩包 $ git archive
一、新建代码库
# 在当前目录新建一个Git代码库 $ git init # 新建一个目录，将其初始化为Git代码库 $ git init [project‐name] # 下载一个项目和它的整个代码历史 $ git clone [url]
Байду номын сангаас
二、配置
Git的设置文件为 .gitconfig ，它可以在用户主目录下（全局配置），也可以在项目目录下（项目配置）。
常用 Git 命令清单
作者： 阮一峰 日期： 2015年12月 9日 我每天使用 Git ，但是很多命令记不住。 一般来说，日常使用只要记住下图6个命令，就可以了。但是熟练使用，恐怕要记住60～100个命令。
下面是我整理的常用 Git 命令清单。几个专用名词的译名如下。
Workspace：工作区 Index / Stage：暂存区 Repository：仓库区（或本地仓库） Remote：远程仓库
git工作原理
git工作原理Git工作原理。
Git是一种分布式版本控制系统，它可以追踪文件的变化，协调多人协作，以及管理项目的版本。
要理解Git的工作原理，首先需要了解Git的基本概念和核心组件。
1. 版本库。
Git的核心是版本库，它包含了项目的所有文件和它们的历史记录。
版本库可以分为本地版本库和远程版本库。
本地版本库是存储在本地计算机上的，而远程版本库通常存储在网络服务器上，用于多人协作。
2. 提交。
在Git中，提交是指将文件的变化保存到版本库中。
每次提交都会生成一个唯一的标识符，用于标记这次提交的内容。
提交可以包括新增、修改、删除文件等操作。
3. 分支。
分支是Git的一个重要概念，它允许在同一时间线上并行开发不同的功能。
每个分支都有自己的提交历史，可以随时切换和合并。
4. 工作区、暂存区和版本库。
在Git中，工作区是指项目的目录，包含了实际的文件。
暂存区是一个缓存区域，用于存放即将提交的文件变化。
版本库则是Git的核心数据库，包含了项目的所有历史记录。
5. 工作流程。
Git的工作流程通常包括以下几个步骤，修改文件、将修改添加到暂存区、提交修改到版本库、推送到远程版本库。
这个过程可以帮助团队协作，保持项目的整体一致性。
6. 远程操作。
Git可以与远程版本库进行交互，常见的操作包括克隆远程版本库、拉取远程分支、推送本地分支等。
这些操作可以帮助团队成员共享代码和协作开发。
7. 分布式特性。
Git是一种分布式版本控制系统，每个开发者都拥有完整的版本库。
这意味着即使在没有网络连接的情况下，开发者仍然可以进行提交和版本控制操作。
总结。
通过以上介绍，我们可以看到Git的工作原理是基于版本库、提交、分支、工作区、暂存区和远程操作等核心概念构建的。
Git的分布式特性使得团队协作更加灵活，同时也提供了强大的版本控制能力。
深入理解Git的工作原理，可以帮助开发者更好地利用Git进行项目管理和版本控制。
Git基本操作流程
Git基本操作流程技术背景Gitee是⼀款国内的git托管服务，对于国内⽤户较为友好，⽤户可以访问来创建⾃⼰的帐号和项⽬，并托管在Gitee平台上。
既然是git的托管服务，那我们就可以先看看git的⼀些基本⽤法：[dechin@dechin-manjaro ~]$ git --help⽤法：git [--version] [--help] [-C <路径>] [-c <名称>=<取值>][--exec-path[=<路径>]] [--html-path] [--man-path] [--info-path][-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare][--git-dir=<路径>] [--work-tree=<路径>] [--namespace=<名称>]<命令> [<参数>]这些是各种场合常见的 Git 命令：开始⼀个⼯作区（参见：git help tutorial）clone 克隆仓库到⼀个新⽬录init 创建⼀个空的 Git 仓库或重新初始化⼀个已存在的仓库在当前变更上⼯作（参见：git help everyday）add 添加⽂件内容⾄索引mv 移动或重命名⼀个⽂件、⽬录或符号链接restore 恢复⼯作区⽂件rm 从⼯作区和索引中删除⽂件sparse-checkout 初始化及修改稀疏检出检查历史和状态（参见：git help revisions）bisect 通过⼆分查找定位引⼊ bug 的提交diff 显⽰提交之间、提交和⼯作区之间等的差异grep 输出和模式匹配的⾏log 显⽰提交⽇志show 显⽰各种类型的对象status 显⽰⼯作区状态扩展、标记和调校您的历史记录branch 列出、创建或删除分⽀commit 记录变更到仓库merge 合并两个或更多开发历史rebase 在另⼀个分⽀上重新应⽤提交reset 重置当前 HEAD 到指定状态switch 切换分⽀tag 创建、列出、删除或校验⼀个 GPG 签名的标签对象协同（参见：git help workflows）fetch 从另外⼀个仓库下载对象和引⽤pull 获取并整合另外的仓库或⼀个本地分⽀push 更新远程引⽤和相关的对象命令 'git help -a' 和 'git help -g' 显⽰可⽤的⼦命令和⼀些概念帮助。
git的基本工作原理
git的基本工作原理一、概述Git是一个分布式版本控制系统，它的基本工作原理是将文件的修改记录保存在本地仓库中，并通过网络同步到远程仓库中。
Git最初由Linus Torvalds开发，用于管理Linux内核的代码。
二、版本控制版本控制是一种管理文件修改历史记录的方法。
它可以帮助团队协作开发，保证代码质量和稳定性。
Git使用了一种称为“快照”的机制来记录文件的修改历史记录。
每次提交都会创建一个新的快照，并将其保存在本地仓库中。
三、本地仓库Git的本地仓库由三个部分组成：工作区、暂存区和版本库。
1. 工作区：指计算机上存储代码文件的目录。
2. 暂存区：也称为索引，是一个缓存区域，用于存放即将提交到版本库中的修改。
3. 版本库：包含了所有提交过的快照和元数据。
四、提交流程Git的基本工作流程包括以下几个步骤：1. 修改文件：在工作区中对文件进行修改。
2. 添加到暂存区：使用git add命令将修改添加到暂存区。
3. 提交到版本库：使用git commit命令将暂存区中的修改提交到版本库中。
五、分支Git的分支是指在代码基础上创建一个新的开发分支，用于并行开发和测试。
每个分支都有自己的快照和版本历史记录。
Git使用了一种称为“引用”的机制来管理分支。
每个引用都指向一个提交对象，表示该分支的最新快照。
六、合并Git的合并是指将两个或多个分支合并成一个。
合并后会生成一个新的提交对象，包含了被合并的所有分支的修改历史记录。
Git使用了一种称为“三方合并”的机制来处理冲突。
七、远程仓库远程仓库是指存储在网络上的版本库，可以供多人协作开发使用。
Git 通过网络协议（如HTTP、SSH等）与远程仓库进行交互。
常见的远程仓库服务包括GitHub、GitLab等。
八、推送与拉取Git通过推送和拉取操作实现本地仓库与远程仓库之间的同步。
1. 推送：使用git push命令将本地仓库中的修改推送到远程仓库中。
2. 拉取：使用git pull命令从远程仓库中拉取最新代码到本地仓库中。
GIT基础教程
Git Diff 魔法
Git Diff
git diff HEAD
HEAD
工 作 区
版库 本
Git diff
暂存 区
git diff --cached master
objects
小结
• • • • 了解Git的工作原理。 了解status的用法。 知道工作区，暂存区之间的区别。 学会diff不同的用法。 diff
git config命令的参数区别 命令的参数区别
执行下面命令，将打开.git/config文件进行编辑 #git config -e 执行下面命令，将打开/home/git/.gitconfig文件进行编辑 #git config -e --global 执行下面命令，将打开/etc/gitconfig系统级配置文件进行编辑 #git config -e --system 以上三个配置文件分别是Git版本库级别的配置文件、全局配置 文件（用户主目录下）和系统级配置文件（/etc目录下）。其优先级 别依次降低。
小结
• 了解Git对象的概念 • 通过ID追踪历史提交
5、Git重置
我们知道，master相当于一个分支游标，每次都指向最新的提交。 但是既然是游标，就应该既可以向上“游动”，也可以向下“游动”。 下面来体会下master游标是怎么变化的 #cat .git/refs/heads/master //查看master指向 #touch new-commit.txt #git add new-commit.txt #git commit -m ”does master change?” #cat .git/refs/heads/master 下面，我们重置下master游标 #git reset --hard HEAD^ #cat .git/refs/heads/master
git的工作流程
git的工作流程Git是一个分布式版本控制系统，被广泛用于软件开发中。
它具有灵活的工作流程，可以帮助团队协同开发和管理代码库。
下面将详细介绍Git的工作流程。
1.初始化仓库在开始使用Git之前，需要先初始化一个仓库。
通过在终端中进入项目文件夹，并执行`git init`命令，就可以创建一个空的Git仓库。
2.创建分支在Git中，分支是一个重要的概念。
每个分支都可以包含一个独立的代码修改历史，并且可以并行进行开发。
通过`git branch`命令可以创建新的分支，例如`git branch dev`会创建一个名为"dev"的新分支。
3.切换分支使用`git checkout`命令可以切换到已存在的分支。
例如`git checkout dev`将当前分支切换到"dev"分支。
进行切换分支操作时，会自动将代码库中的文件切换到相应分支的代码状态。
4.添加和提交5.合并分支当在不同的分支上开发完成后，需要将不同分支的代码合并起来。
使用`git merge`命令可以将指定分支的修改合并到当前分支。
例如`git merge dev`将"dev"分支的修改合并到当前分支。
6.提交到远程仓库在团队协同开发中，通常会使用远程仓库来共享代码。
使用`git remote add`命令可以将远程仓库添加到本地代码库中。
例如`git remote add origin <remote repository>`。
然后使用`git push`命令可以将本地代码库的修改推送到远程仓库，例如`git push origin master`将代码推送到名为"origin"的远程仓库的"master"分支。
7.拉取远程更新当其他开发人员对代码库进行修改并推送到远程仓库后，需要及时获取最新的代码修改。
使用`git pull`命令可以从远程仓库拉取更新到本地仓库，例如`git pull origin master`将最新的"master"分支的代码拉取到本地仓库。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Git 工作流程(阮一峰完整总结版本，各流程变化，且有独到
见解)
Git 作为一个源码管理系统，不可避免涉及到多人协作。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。
"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
本文介绍三种广泛使用的工作流程：
Git flow
Github flow
Gitlab flow
如果你对Git还不是很熟悉，可以先阅读下面的文章。
《Git 使用规范流程》
《常用Git 命令清单》
《Git 远程操作详解》
一、功能驱动
本文的三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。
完成开
发后，该分支就合并到主分支，然后被删除。
二、Git flow
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
2.1 特点
它最主要的特点有两个。
首先，项目存在两个长期分支。
主分支master
开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，
都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
Git flow 的详细介绍，请阅读我翻译的中文版《Git 分支管理策略》。
2.2 评价
Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。
大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。
更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。
但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。
这时，master分支和develop 分支的差别不大，没必要维护两个长期分支。
三、Github flow
Github flow 是Git flow的简化版，专门配合"持续发布"。
它是 使用的工作流程。
3.1 流程
它只有一个长期分支，就是master，因此用起来非常简单。
官方推荐的流程如下。
第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。
对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。
（先部署再合并也可。
）
3.2 评价
Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。
问题在于它的假设：master分支的更新与产品的发布是一致的。
也就是说，master分支的最新代码，默认就是当前的线上代码。
可是，有些时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。
比如，苹果商店的APP提交审核以后，等一段时间才能上架。
这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。
另一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会导致线上版本落后于master分支。
上面这种情况，只有master一个主分支就不够用了。
通常，你不得不在master分支以外，另外新建一个production分支跟踪线上版本。
四、Gitlab flow
Gitlab flow 是Git flow 与Github flow 的综合。
它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
它是 推荐的做法。
4.1 上游优先
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。
只有上游分支采纳的代码变化，才能应用到其他分支。
Chromium项目就是一个例子，它明确规定，上游分支依次为：
Linus Torvalds的分支
子系统（比如netdev）的分支
设备厂商（比如三星）的分支
4.2 持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。
对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。
比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。
代码的变化，必须由"上游"向"下游"发展。
比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
4.3 版本发布
对于"版本发布"的项目，建议的做法是每一个稳定版本，都
要从master分支拉出一个分支，比如2-3-stable、2-4-stable 等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
五、一些小技巧
5.1 Pull Request
功能分支合并进master分支，必须通过Pull Request（Gitlab 里面叫做Merge Request）。
前面说过，Pull Request本质是一种对话机制，你可以在提交的时候，@相关人员或团队，引起他们的注意。
5.2 Protected branch
master分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批Pull Request 的权力。
Github 和Gitlab 都提供"保护分支"（Protected branch）这个功能。
5.3 Issue
Issue 用于Bug追踪和需求管理。
建议先新建Issue，再新建对应的功能分支。
功能分支总是为了解决一个或多个Issue。
功能分支的名称，可以与issue的名字保持一致，并且以issue的编号起首，比如
"15-require-a-password-to-change-it"。
开发完成后，在提交说明里面，可以写上"fixes #14"或者"closes #67"。
Github规定，只要commit message里面有下面这些动词+ 编号，就会关闭对应的issue。
close
closes
closed
fix
fixes
fixed
resolve
resolves
resolved
这种方式还可以一次关闭多个issue，或者关闭其他代码库的issue，格式是username/repository#issue_number。
Pull Request被接受以后，issue关闭，原始分支就应该删除。
如果以后该issue重新打开，新分支可以复用原来的名字。
5.4 Merge节点
Git有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另一种是"非直进式合并"（none
fast-forword），会生成单独节点。
前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用--no-ff参数）。
只要发生合并，就要有一个单独的合并节点。
5.5 Squash 多个commit
为了便于他人阅读你的提交，也便于cherry-pick或撤销代码变化，在发起Pull Request之前，应该把多个commit合并成一个。
（前提是，该分支只有你一个人开发，且没有跟master合并过。
）
这可以采用rebase命令附带的squash操作，具体方法请参考我写的《Git 使用规范流程》。
（完）。