git 提交代码流程

ldj2020

已于 2025-06-30 21:05:48 修改

阅读量655

点赞数 1

CC 4.0 BY-SA版权

分类专栏： git 文章标签： git

于 2024-11-06 23:25:54 首次发布

本文链接：https://blog.csdn.net/dj1955/article/details/143582283

git 专栏收录该内容

1 篇文章

订阅专栏

工作区：当前正在工作的目录，包含了最新的修改。
暂存区（Index）：位于工作区和仓库之间，用于暂存即将提交的更改。
本地仓库：存储所有提交的历史记录，每个提交都有一个唯一标识符（SHA-1哈希值）。

1. 公-->私-->本-->私-->公（一般用于不同团队合作）

缺点：多了一个步骤，就多了一次申请时间，首先在公仓申请合并到私仓，私仓同意合并，获取到公仓最新版本；

优点：不容易污染公仓

2. 公-->本-->私-->公

优点：简化操作，因为每次都可以直接pull都是最新代码

缺点：因为放开了公仓的权限，如果直接push到公共仓库躲过代码公审，容易造成公仓污染

公->本->私->公 (分支名称：241107)

# 先将本地修改暂存起来，idea 里修改文件由蓝-->白

git stash save "暂存2024110701"

# 拉取公仓最新代码，期间要数据账号密码

git pull origin 241107

# 恢复自己最新修改的文件，idea 里修改文件由白-->蓝

git stash pop

# 查看修改文件，显示红色相对路径

git status

# 复制红色修改的文件相对路径，添加到暂存区，（如果修改文件多，一个一个添加）

git add <红色相对路径>

# 检查是否add完毕，红色相对路径应该全变绿色

git status

# 提交暂存区

git commit -m "提交注释"

# 推送到私仓(person名称是我自定义的，它映射一个仓库地址，idea的可以配置的)

git push person 241107

# 最后在私仓的web页面申请合并到公仓，公仓审核员审核通过，就可以合并

总结：企业里一般采用第一种方式，还有是下面这种，与上面两种主要区别是多了一个私仓

3. 代码回滚

代码冲突定义：修改同一个文件的相同行或者相邻行，就会包冲突

参考： Git恢复之前版本的两种方法reset、revert（图文详解）【学习】_git还原到上一个版本CSDN博客

3.1 手动删除

适用场景：只想回滚自己那部分代码，并且量比较少，不想要也没关系，要也可以再巴巴拉拉写出来的。

具体做法把你要删除的代码，先拷贝出来，拷贝目的是能恢复修改代码，然后删除你bug代码，最后push到远程仓库

3.2 reset重置

适用场景：本地仓库恢复到指定版本，且这个版本之后的提交都不要了，能不用就不用！必须用要慎用！

例子：个人提交垃圾到远程仓库而且量比较大，如那些什么说明文件等，不好通过手动删除垃圾的方式解决问题

# 查看版本号（idea也可以操作，自行百度）

git log

# 重置指定版本

--hard 本地版本仓库回退指定版本,工作区和暂存区3区全部回退

--soft 本地版本仓库回退指定版本，工作区和暂存区不回退

--mixed 本地版本仓库回退指定版本,暂存区也回退，工作区不回退

git reset --hard <版本号>

# 使用-f 强制低版本覆盖高版本（如果已经提交到远程，需要更新远程）

git push -f origin <分支名称>

3.3 revert 撤销（更符合实际场景，推荐使用）

适用场景：要撤销之前某个bug版本2,又不想把后面版本3删除

原理：生成个新的版本4，版本4会保留bug版本2后面的提交，但是撤销了bug版本2

# 查看版本号（idea也可以操作，自行百度）

git log

# 本地撤销

git revert -n <bug版本号>

# 同步远程仓库

git push origin xxxx分支

git 常用命令

# 将当前目录交给git 管理
git init

# 克隆代码 （1.初始化本地库 2.拉取代码 3. 创建别名 ）
git clone  <远程仓库地址>

# 查看文件状态，红色：未被跟踪的文件，绿色：已经被跟踪的文件
git status

# 要添加的修改文件
git add <未被跟踪的文件（红色）>

# 删除缓存区的文件
git rm -cached <已经被跟踪的文件 （绿色）>

# 提交代码前，先同步远程代码
git pull <远程仓库地址 or 别名>  <远程分支名称>

# 提交本地库，记录跟踪历史
git commit -m  <提交日志信息> <已经被跟踪的文件>

# 推送远程仓库
git push <远程仓库地址>

# 查看精简信息
git reflog

# 查看详细信息
git log

# 推送到远程代码托管中心
git push <远程仓库地址 or 别名> <远程分支名称>

# 版本穿梭
git reflog
git reset --hard <版本号>


# 分支操作

1.查看分支 git branch -v

2.创建分支 git branch <新分支名称>

3.切换分支 git checkout <新分支名称>

4.合并分支 
git checkout <主分支>
git merge <新分支名称>

# 查看远程分支
git remote -v

标准工作流程：

1.开始修改前先执行 pull：确保本地代码是最新的

2.进行功能开发或 bug 修复，完成后提交本地更改（git add + git commit）

3.在推送远程仓库之前，再次执行 pull：确保远程没有新提交导致冲突

4.解决可能出现的问题后，最后执行 push。


第二次 pull 有时会失败的原因及处理方式

成功情况：

即便远程有新的提交，只要这些提交不涉及你正在工作的文件或者它们之间的修改不重叠，Git 可以自动合并这些更改，不会引发冲突。

失败情况：

1. 工作区存在未提交的更改
分析：
当你在本地对文件进行了新增、修改或删除操作，但尚未将这些更改提交到本地仓库时，Git 认为直接进行 pull 操作可能会覆盖你尚未保存的工作，因此阻止了这一操作。

解决：
完成提交：如果你对当前的更改感到满意，可以通过以下步骤来提交它们：
git add . 将所有修改添加到暂存区。
git commit -m "描述你的更改" 来提交更改。


如果修改还未完成，可以使用 git stash 来暂时保存它们：
git stash 暂存更改：
git stash save "临时保存未提交的更改"。
git pull origin master（或你正在工作的分支名）。
git stash pop。

2. 暂存区存在未提交的文件
分析：
如果你已经通过 git add 命令将某些文件添加到了暂存区，但是还没有执行 git commit 提交这些更改，Git 同样认为当前状态不干净，并阻止 pull 操作。

解决：
直接提交：如果决定保留当前的更改，可以直接完成提交过程：
执行 git commit -m "描述你的更改"。
取消暂存：如果你希望先拉取最新代码，可以选择取消暂存：
执行 git reset，这将把暂存区的所有更改移回工作区，之后你可以根据需要决定是先 pull 还是先处理这些更改。

3. 代码自动合并冲突
分析：

当远程仓库中的文件与本地文件在同一部分发生了不同的修改时，Git 无法自动决定如何合并这些更改，这时就会产生冲突。通常这种情况发生在你和团队成员同时对同一文件的相同部分进行了修改。
解决：

查看冲突文件：使用 git status 查看哪些文件存在冲突。
手动解决冲突：打开每个冲突文件，按照提示编辑文件，选择保留哪些更改。例如，你可能看到类似如下的标记：
Diff
深色版本
<<<<<<< HEAD
// 你的本地更改
=======
// 远程的更改
>>>>>>> branch-name


根据实际情况编辑文件，决定保留哪些更改。完成后，标记冲突已解决：git add <file>。
完成合并：一旦所有冲突都已解决并且相应的文件已被标记为解决，你可以完成合并过程：git commit -m "解决了合并冲突"。
沟通协作：如果有疑问或者不确定如何处理某些冲突，最好与团队成员讨论，确保所有人都同意最终的解决方案。