Git提交规范(git 手动解决冲突后,怎么提交)-东辰安华生活网

Git提交规范(git 手动解决冲突后,怎么提交),本文通过数据整理汇集了Git提交规范(git 手动解决冲突后,怎么提交)相关信息，下面一起看看。

Git是我们程序员吃饭的工具。主要是针对提交和分支，以及大部分程序员都被吓到的关于punch的一些个人见解。如果贵公司的git提交流程有任何问题，请在下面评论。

在讨论规范之前，我们需要设置最基本的需求。

1.在团队内部保持良好的代码格式，便于阅读和维护，最重要的是减少不必要的代码冲突(建议统一使用开发工具(idea)的代码格式)。

2.提交的任何代码都必须确认代码可以运行。

3.提交的代码一定要去掉无用的包路径引用和无用的依赖，尽量不要使用过时的方法或类。

1 .提交消息规范格式：

类型：主题类型

特性：新特性)修复：修复bug、风格等。重构：重构(即不是新特性，也不是修改bug的代码更改)测试：添加测试苦差事：构建过程中的更改或辅助工具主题

提交目的的简要描述，描述已经做了什么或改变了什么。如果有团队管理工具(issue，JIRA)或产品需求，内部命名的需求代码必须作为描述信息的一部分，方便查看日志、合并和挑选。

示例：

功能：开发完成#代码XXX。XXX需求修复：修改#代码XXXX查询问题

2.提交规范和GIT开发流程

Git分支

Master(生产环境)当uat功能部署到准生产时，它将被合并到master中。只有uat分支可以被合并/精选。Uat(测试环境)部署一个特性分支进行测试，并将其合并到uat中。仅允许合并要素分支。Feature/xxxx (feature branch)在开发一个特性或者修改一个bug的时候合并/提交到feature dev/xx(local development version)。

在开发之前，你需要切割一个以需求、bug、重构等命名的特性分支。在主分支上，比如特性/项目号(bug的代码)。

2.1如果本地没有项目克隆代码，切换到开发分支克隆，在需要开发的特性分支上创建一个本地dev开发分支。当地分支机构可以用英语命名，带有开发人员/自我标识。

Git clone -b dev/xx特性/项目编号2.2有一个本地项目切换开发分支。为了避免本地分支和远程分支不一致，需要切换到特性/项目号分支并更新。

Git checkout特性/项目号git pull在特性/项目号上切出自己的开发分支。

Git checkout dev/xx 2.3提交代码注意：不需要提交的后缀或文件必须添加到。gitignore文件与。饭桶。

将修改后的文件添加到临时区域。

Git添加。将修改后的文件提交到本地版本库。

Git commit -m 'fix: modified XXXXX '也可以两步组合，一步操作。

Git commit -am 'fix: XXXXX '已修改。

提交代码。个人建议最好使用idea或者其他git图形界面来查看需要添加的文件，或者操作。

git后图标的含义

第一个是git拉代码操作按钮，第二个是git提交操作按钮，第三个是git日志操作按钮，第四个是git还原操作按钮。首先点击git提交按钮。

点击提交按钮，可以清楚的看到git的状态，哪些文件被修改，哪些文件需要提交给git，哪些文件不需要提交给git。如果它是临时的或不令人兴奋，您可以使用revert在修改之前恢复它。

如果这个文件不需要修改，或者不小心使用了空格等操作，直接用revert恢复。

如果这个文件是项目启动时生成的，比如项目导出的excel或者log log，直接删除。

提示：在开发过程中，可以随时进入上图所示的提交界面，直观的看到哪些文件发生了变化，更方便高效的管理自己修改的内容。其他桌面图形也是可能的，比如Tortoisegit、Source Tree以及git附带的两个gitks和git-gui(在git目录中输入命令)。

2.4推送到远程分支当本地分支dev推送到远程dev时，需要切换到特征/项目号分支，合并远程分支代码。

Git checkout特性/项目号git pull并切换到自己的开发分支dev/xxx。

Git checkout dev/xxx rebase特性/项目号到自己的dev/xxx，主要作用是检查是否有冲突。

git rebase特性/项目号之间没有冲突，直接推dev/xxx到远程dev/xxx。

git推送原点开发/xxx

如果存在冲突，您可以在合并冲突后的任何时候使用git status命令来查看那些由于包含合并冲突而处于未合并状态的文件。

Git状态所有在合并中有冲突并需要解决的文件将被标识为未合并。Git会给有冲突的文件添加标准的冲突解决标记，这样你就可以打开这些包含冲突的文件，手动解决它们。

HEAD:index.htmldiv id='footer '联系人：email . support @ github 0.7508333493119754 . com 0.32907915229713613/Div=======Div ID=' footer '请联系我们support @ github 0.7508333493119754 . com 0.3290791529713613/Div dev/xx:index.html以上

======是分割线，上半部分是head指向的分支的版本代码，下半部分是dev/xx分支指向的版本代码。

上面的冲突解决方法只保留了一个分支的修改，并且=======，这些行需要全部删除。

修改完成后需要采取措施。

Git添加。使用git add命令将其标记为冲突已解决。一旦这些最初冲突的文件被临时存储，Git会将它们标记为已解决。

然后继续重置基础操作：

Gitrebase - continue继续循环rebase - continue，直到rebase成功。

然后推

Git推送origin dev/xxx最后登录gitlab或coding的web管理，提交合并请求，将远程分支dev/xxx与远程分支特性/项目号分支合并。合并后，您的提交就完成了。功能分支开发完成并通过测试后，功能将合并到uat中进行在线测试。

现在让我们看看如何借助我们的工件思想来解决冲突。

在合并、重定基础、精选等操作中，当有冲突时，就会出现冲突。

最好不要直接选择使用远程还是自修改代码，或者单独点击文件选择每行的修改。

解决完了，直接涂抹推就好了。

总结：

就git而言，只有push和pull操作会处理远程操作，其他命令都在本地完成，也就是说，只有在git平台上直接发起pull、push或者远程分支和远程分支合并请求，才能真正知道有冲突。即使是本地rebase feature，仍然没有办法保证dev和feature之间没有冲突，因为当你rebase的时候，并不能说明你当前本地feature分支的代码和你发起合并请求的时候feature分支的代码是完全一样的，所以rebase feature只是减少了提前合并feature时的冲突。

至于git操作的过程，每个人的使用习惯都有些不同。其实怎么操作都没什么问题。如果公司和团队已经认可了规范，他们仍然应该遵循它们。

常见的提交方法：

1.直接在特征分支中开发。大家在提交前拉(gitfetch gitmerge)新特性的代码，然后添加。冲突一劳永逸解决后提交推送。

2.直接在特征分支中开发。大家先提交到本地分支，然后pull-rebase(git fetch gitrebase)当前新特性的代码，再添加add。冲突解决后再推。

3.就是我上面写的严格操作。每个人都有一个自己命名的本地开发分支。它可以通过与要合并的本地分支机构合并或重定基来解决冲突，然后通过web平台的请求进行合并。

4.欢迎提供更多牛逼的方法。

第一种是最简单也是最常见的操作方式。很容易在解决冲突时丢失自己修改过的代码，把它操成不可挽回的结果。(可以用idea的本地历史来回滚。)

第二，先提交，再拉代码rebase，可以保证你的代码提交到本地分支。无论您后来如何盲目地更改代码，您都不会丢失这个提交的commit。

第三，操作有点复杂。虽然绕了一点，但和第二个相比，主要区别在于特征分支是否允许直接提交。如果允许，那么将特征合并的权限控制放在合并到uat的环节中。

简单理解：GIT的操作无非就是拉代码、推代码、合并代码，处理远程分支的操作真的每一步都会冲突。但是提前解决矛盾或者用什么方式解决矛盾是有很多方法的。

不管你用什么图形化工具，我们都需要搞清楚git的基本命令，以及每一步图形化工具操作背后git操作的命令。

警告：不要删除。git目录有没有推送代码，你懂的。