ToB企服应用市场:ToB评测及商务社交产业平台

标题: Git指南-从入门到精通 [打印本页]

---

作者: 熊熊出没    时间: 2025-2-13 07:52
标题: Git指南-从入门到精通
代码提交和同步命令

流程图如下：

• 第零步: 工作区与仓库保持同等
  
• 第一步: 文件增编削，变为已修改状态
  
• 第二步: git add <冲突文件>，变为已暂存状态
  

1. $ git status
2. $ git add <冲突文件>--all # 当前项目下的所有更改
3. $ git add <冲突文件>.  # 当前目录下的所有更改
4. $ git add <冲突文件>xx/xx.py xx/xx2.py  # 添加某几个文件

复制代码

• 第三步: git commit，变为已提交状态
  

1. $ git commit -m "<这里写commit的描述>"

复制代码

• 第四步: git push，变为已推送状态
  

1. $ git push -u origin master # 第一次需要关联上
2. $ git push # 之后再推送就不用指明应该推送的远程分支了
3. $ git branch # 可以查看本地仓库的分支
4. $ git branch -a # 可以查看本地仓库和本地远程仓库(远程仓库的本地镜像)的所有分支

复制代码

一般来说，在某个分支下，最常用的操作如下：

1. $ git status
2. $ git add <冲突文件>-a
3. $ git status
4. $ git commit -m 'xxx'
5. $ git pull --rebase
6. $ git push origin xxbranch

复制代码

代码撤销和撤销同步命令

流程图如下：

已修改，但未暂存

1. $ git diff # 列出所有的修改
2. $ git diff xx/xx.py xx/xx2.py # 列出某(几)个文件的修改
4. $ git checkout <file-name># 撤销项目下所有的修改
5. $ git checkout <file-name>. # 撤销当前文件夹下所有的修改
6. $ git checkout <file-name>xx/xx.py xx/xx2.py # 撤销某几个文件的修改
7. $ git clean -f # untracked状态，撤销新增的文件
8. $ git clean -df # untracked状态，撤销新增的文件和文件夹
10. # Untracked files:
11. #  (use "git add <冲突文件><file>..." to include in what will be committed)
12. #
13. #        xxx.py

复制代码

git checkout 与后文的切换分支命令几乎同等，究竟上，checkout 作为单个命令有点超载（它承载了许多独立的功能），因此在 Git 2.23 版本中，引入了一个名为 git switch 的新命令，最终会代替 git checkout

已暂存，未提交

这个时候已经执行过git add，但未执行git commit，但是用git diff已经看不到任何修改。 因为git diff检查的是工作区与暂存区之间的差异。

1. $ git diff --cached # 这个命令显示暂存区和本地仓库的差异
3. $ git reset <file-name># 暂存区的修改恢复到工作区
4. $ git reset <file-name>--soft # 与git reset等价，回到已修改状态，修改的内容仍然在工作区中
5. $ git reset <file-name>--hard # 回到未修改状态，清空暂存区和工作区

复制代码

git reset --hard 操作等价于 git reset 和 git checkout 2步操作

已提交，未推送

执行完commit之后，会在仓库中天生一个版本号(hash值)，标志这次提交。之后任何时候，都可以借助这个hash值回退到这次提交。

1. $ git diff <branch-name1> <branch-name2> # 比较2个分支之间的差异
2. $ git diff master origin/master # 查看本地仓库与本地远程仓库的差异
4. $ git reset <file-name>--hard origin/master # 回退与本地远程仓库一致
5. $ git reset <file-name>--hard HEAD^ # 回退到本地仓库上一个版本
6. $ git reset <file-name>--hard <hash code> # 回退到任意版本
7. $ git reset <file-name>--soft/git reset # 回退且回到已修改状态，修改仍保留在工作区中。

复制代码

已推送到远程

1. $ git push -f orgin master # 强制覆盖远程分支
2. $ git push -f # 如果之前已经用 -u 关联过，则可省略分支名

复制代码

慎用，一般情况下，本地分支比远程要新，所以可以直接推送到远程，但有时推送到远程后发现有问题，进行了版本回退，旧版本或者分叉版本推送到远程，需要添加 -f参数，表现逼迫覆盖。

其它常用命令

关联远程仓库

• 如果还没有Git仓库，需要初始化
  

1. $ git init

复制代码

• 如果想关联远程仓库
  

1. $ git remote add <name> <git-repo-url>
2. # 例如 git remote add origin https://github.com/xxxxxx # origin是远程仓库的名称

复制代码

• 如果想关联多个远程仓库
  

1. $ git remote add <name> <another-git-repo-url>
2. # 例如 git remote add coding https://coding.net/xxxxxx

复制代码

• 查看关联了哪些仓库或者地址
  

1. $ git remote -v
2. # origin https://github.com/Seven-97/SevenBlog.git (fetch)
3. # origin https://github.com/Seven-97/SevenBlog.git (push)

复制代码

• 如果远程有仓库，需要clone到本地
  

1. $ git clone <git-repo-url>
2. # 关联的远程仓库将被命名为origin，这是默认的。

复制代码

• 如果想把别人仓库的地址改为自己的
  

1. $ git remote set-url origin <your-git-url>

复制代码

配置自己的Git

• 查看当前的配置
  

1. $ git config --list

复制代码

• 配置自己的名字
  

1. $ git config --global user.name "<name>"
2. #  --global为可选参数，该参数表示配置全局信息

复制代码

• 盼望别人看到你的commit可以联系到你
  

1. $ git config --global user.email "<email address>"

复制代码

• 有些命令很长，能不能简化一下
  

1. $ git config --global alias.logg "log --graph --decorate --abbrev-commit --all"
2. # 之后就可以开心地使用 git log了

复制代码

​
切换分支

新建仓库后，默认天生了master分支

• 新建分支并切换
  

1. $ git checkout <file-name>-b <new-branch-name>
2. # 例如 git checkout -b dev
3. # 如果仅新建，不切换，则去掉参数 -b

复制代码

• 查看当前有哪些分支
  

1. $ git branch
2. # * dev
3. #   master # 标*号的代表当前所在的分支

复制代码

• 查看当前本地&远程有哪些分支
  

1. $ git branch -a
2. # * dev
3. #   master
4. #   remotes/origin/master

复制代码

• 切换到现有的分支
  

1. $ git checkout <file-name>master

复制代码

更新本地/远端代码 push/poll

• 将本地master分支推送到远程去
  

1. $ git push origin master
2. # 你可以使用git push -u origin master将本地分支与远程分支关联，之后仅需要使用git push即可。

复制代码

• 远程分支更新了，需要更新代码
  

1. $ git pull origin <branch-name>
2. # 之前如果push时使用过-u，那么就可以省略为git pull

复制代码

• 本地有修改，能不能先git pull
  

1. $ git stash # 工作区修改暂存
2. $ git pull  # 更新分支
3. $ git stash pop # 暂存修改恢复到工作区

复制代码

git pull 实际上包含了两个操作：fetch和merge。当使用git pull命令时，Git会自动下载最新代码，并尝试将最新代码合并到当前分支。git fetch命令只是从远程库下载最新代码，但并不自动合并到本地分支。

• 如果我们盼望自动合并最新代码到当前分支，而且不需要查看最新代码的变更，可以使用git pull命令。
  
• 如果我们只想下载最新代码到本地，并需要查看最新代码的变更后才决定是否进行合并，可以使用git fetch命令。
  

撤销操作 reset

• 恢复暂存区文件到工作区
  

1. $ git checkout <file-name>

复制代码

• 恢复暂存区的所有文件到工作区
  

1. $ git checkout <file-name>.

复制代码

• 重置暂存区的某文件，与上一次commit保持同等，但工作区不变
  

1. $ git reset <file-name>

复制代码

• 重置暂存区与工作区，与上一次commit保持同等
  

1. $ git reset <file-name>--hard # 如果是回退版本(commit)，那么file，酿成commit的hash码就好了。

复制代码

• 去掉某个commit
  

1. $ git revert <commit-hash>
2. # 实质是新建了一个与原来完全相反的commit，抵消了原来commit的效果

复制代码

• reset回退错误恢复
  

1. $ git reflog #查看近来操作记录$ git reset <file-name>--hard HEAD{5} #恢复到前五笔操作$ git pull origin backend-log #再次拉代替码

复制代码

版本回退与前进 status、log、reflog

• 查看当前状态
  

1. $ git status

复制代码

• 查看汗青版本
  

1. $ git log
2. commit 9a3d34be1e26563e198ee6aea72d32ad68b607d0 (HEAD -> main, origin/main, origin/HEAD)
3. Author: seven <415849169@qq.com>
4. Date:   Tue Jul 9 19:10:11 2024 +0800
6.     更新
8. commit 47c32de67a28df58ea3bd0b88137f1bd19a12969
9. Author: Seven <415849169@qq.com>
10. Date:   Tue Jul 9 00:30:11 2024 +0800
12.     更新
14. commit 294814faf55fc4f01e3b0a28c96b5acdf1348333
15. Author: Seven <415849169@qq.com>
16. Date:   Tue Jul 9 00:22:15 2024 +0800
18.     更新内容
20. commit 15026d42c4d3a6093bde4578484e2bb64824b9e8
21. Author: Seven <415849169@qq.com>

复制代码

• 这样的log不好看，可以试试以下命令
  

1. $ git log --graph --decorate --abbrev-commit --all
2. * commit 9a3d34b (HEAD -> main, origin/main, origin/HEAD)
3. | Author: seven <415849169@qq.com>
4. | Date:   Tue Jul 9 19:10:11 2024 +0800
5. |
6. |     更新
7. |
8. * commit 47c32de
9. | Author: Seven <415849169@qq.com>
10. | Date:   Tue Jul 9 00:30:11 2024 +0800
11. |
12. |     更新
13. |
14. * commit 294814f
15. | Author: Seven <415849169@qq.com>
16. | Date:   Tue Jul 9 00:22:15 2024 +0800
17. |
18. |     更新内容
19. |
20. * commit 15026d4
21. | Author: Seven <415849169@qq.com>
22. | Date:   Tue Jul 9 00:16:23 2024 +0800

复制代码

• 检出到任意版本
  

1. $ git checkout <file-name>a5d88ea# hash码很长，通常6-7位就够了

复制代码

• 远程仓库的版本很新，但是还是想用老版本覆盖
  

1. $ git push origin master --force
2. # 或者 git push -f origin master

复制代码

• 觉得commit太多了? 可以使用rebase将多个commit合并为1个
  

1. $ git rebase -i HEAD~4
2. # 这个命令，将最近4个commit合并为1个，HEAD代表当前版本。将进入VIM界面，你可以修改提交信息。推送到远程分支的commit，不建议这样做，多人合作时，通常不建议修改历史。

复制代码

• 想回退到某一个版本
  

1. $ git reset <file-name>--hard # 例如 git reset --hard a3hd73r# --hard代表抛弃工作区的修改，让工作区与版本代码一模一样，与之对应，--soft参数代表保留工作区的修改。

复制代码

• 想回退到上一个版本，有没有简便方法?
  

1. $ git reset <file-name>--hard HEAD^

复制代码

• 回退到上上个版本呢?
  

1. $ git reset <file-name>--hard HEAD^^# HEAD^^可以换作具体版本hash值。

复制代码

• 回退错了，想到下一个版本
  

1. $ git reflog
2. # 这个命令保留了最近执行的操作及所处的版本，每条命令前的hash值，则是对应版本的hash值。使用上述的git checkout 或者 git reset命令 则可以检出或回退到对应版本。

复制代码

• 刚才commit信息写错了，修改上一次提交的commit信息
  

1. $ git commit --amend

复制代码

分支合并 merge

每个分支上都有各自独有的提交，这意味着没有一个分支包含了修改的所有内容。因此通过合并分支来办理这个问题。
git merge 用来做分支合并，将其他分支中的内容合并到当前分支中。比如分支结构如下：

其它分支合并到master分支

当前分支是master

1. git checkout master

复制代码

把issueFix中的内容Merge进来：

1. git merge issueFix

复制代码

如果没有冲突的话，merge完成。有冲突的话，git会提示那个文件中有冲突，比如有如下冲突：

1. <<<<<<< HEAD:test.c
2. printf (“test1″);
3. =======
4. printf (“test2″);
5. \>>>>>>> issueFix:test.c

复制代码

可以看到 ======= 隔开的上半部分，是 HEAD（即 master 分支，在运行 merge 命令时检出的分支）中的内容，下半部分是在 issueFix 分支中的内容。
办理冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来办理：

1. printf (“test2″);

复制代码

这个办理方案各接纳了两个分支中的一部分内容，而且删除了  这些行。在办理了所有文件里的所有冲突后，运行 git add <冲突文件>将把它们标记为已办理（resolved）。因为一旦暂存，就表现冲突已包办理。
合并后的分支图如下：

留意，这次合并的实现，由于当前 master 分支所指向的 commit (C4)并非想要并入分支（issueFix）的直接祖先，Git 不得不进行一些处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）和它们的共同祖先（C2）进行一次简朴的三方合并。对三方合并的结果作一新的快照，并自动创建一个指向它的 commit（C6)
退出合并工具以后，Git 会询问你合并是否成功。如果答复是，它会为你把相关文件暂存起来，以表明状态为已办理。然后可以用 git commit 来完成这次合并提交。
因此，多人协作的工作模式通常是这样：

• 首先，可以试图用git push origin 推送自己的修改；
  
• 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  
• 如果合并有冲突，则办理冲突，并在本地提交；
  
• 没有冲突或者办理掉冲突后，再用git push origin 推送就能成功！
  
• 如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to origin/。
  

master分支合并到当前分支

以下是合并master分支到你的当前分支的基本步骤：

• 确保在正确的分支上：首先，确保当前所在的分支是想要合并master分支到的地方。例如，如果想要将master合并到feature-branch，需要先切换到feature-branch：
  1. git checkout feature-branch

  复制代码
• 更新分支：在合并之前，最好先更新分支，以确保它是最新的。可以通过拉取master分支的最新更改来实现这一点：
  1. git pull origin master

  复制代码
  这会从远程仓库的master分支拉取最新的更改，并尝试将它们合并到你的当前分支。如果master分支有新的提交，这可能会导致合并冲突。
  
• 合并master分支：一旦分支是最新的，可以开始合并过程。使用git merge命令来合并master分支：
  1. git merge master

  复制代码
  这会将master分支的更改合并到当前分支。如果两个分支之间没有冲突，合并将自动完成。如果有冲突，Git会告诉你哪些文件有冲突，此时就需要手动办理这些冲突。
  
• 办理冲突（如果有）：如果合并过程中出现冲突，Git会暂停合并并告诉你哪些文件需要手动办理冲突。你需要打开这些文件，找到并办理冲突。办理冲突后，使用以下命令标记冲突已办理：
  1. git add <冲突文件>

  复制代码
  然后继续合并：
  1. git commit

  复制代码
  这将创建一个新的合并提交，包含所有办理的冲突。
  
• 推送更改：一旦合并完成而且所有冲突都已办理，你可以将更改推送到远程仓库：
  1. git push origin feature-branch

  复制代码
  确保替换feature-branch为你的分支名称。
  

留意事项

• 在合并之前，始终确保你的分支是最新的，以避免不必要的冲突。
  
• 如果你在合并过程中遇到问题，可以使用git merge --abort来中止合并并返回到合并前的状态。
  
• 使用git log或gitk可以帮助理解分支的汗青和可能的冲突点。
  

Git代码管理规范

分支定名

master 分支

master 为主分支，也是用于部署生产情况的分支，需要确保master分支稳定性。master 分支一般由 release 以及 hotfix 分支合并，任何时间都不能直接修改代码。
develop 分支

develop 为开发情况分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一般开发的新功能时，feature分支都是基于develop分支创建的。
feature 分支

开发新功能时，以develop为底子创建feature分支。
分支定名时以 feature/ 开头，后面可以加上开发的功能模块， 定名示例：feature/user_module、feature/cart_module
test分支

test为测试情况分支，外部用户无法访问，专门给测试人员使用，版本相对稳定。
release分支

release 为预上线分支（预发布分支），UAT测试阶段使用。一般由 test 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
hotfix 分支

线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。修复完成后，需要合并到 master 分支和 develop 分支。
分支定名以hotfix/ 开头的为修复分支，它的定名规则与 feature 分支类似。
分支与情况对应关系

在系统开发过程中常用的情况：

• DEV 情况（Development environment）：用于开发者调试使用
  
• FAT情况（Feature Acceptance Test environment）：功能验收测试情况，用于测试情况下的软件测试者测试使用
  
• UAT情况 （User Acceptance Test environment）：用户验收测试情况，用于生产情况下的软件测试者测试使用
  
• PRO 情况（Production environment）：生产情况
  

对应关系：
分支功能情况可访问master主分支，稳定版本PRO是develop开发分支，最新版本DEV是feature开发分支，实现新特性否test测试分支，功能测试FAT是release预上线分支，发布新版本UAT是hotfix紧急修复分支，修复线上bug否分支合并流程规范

业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：

以上生命周期仅作参考，差别开发团队可能有差别的规范，可自行灵活定义。
Git Commit Message规范

Git commit message规范指提交代码时编写的规范注释，编写良好的Commit messages可以达到3个重要的目标：

• 加速代码review的流程
  
• 帮助我们编写良好的版本发布日志
  
• 让之后的维护者了解代码里出现特定变化和feature被添加的缘故原由
  

Angular Git Commit Guidelines

业界应用的比较广泛的是Angular Git Commit Guidelines：

1. <type>(<scope>): <subject>
2. <BLANK LINE>
3. <body>
4. <BLANK LINE>
5. <footer>

复制代码

• type：提交范例
  
• scope：可选项，本次 commit 波及的范围
  
• subject：简明扼要的论述下本次 commit 的主旨，在Angular Git Commit Guidelines中强调了三点。使用祈使句，首字母不要大写，结尾无需添加标点
  
• body: 同样使用祈使句，在主体内容中我们需要把本次 commit 具体的描述一下，比云云次变更的动机
  
• footer: 描述下与之关联的 issue 或 break change
  

简易版

项目中实际可以采用简易版规范：

1. <type>(<scope>):<subject>

复制代码

type规范

Angular Git Commit Guidelines中保举的type范例如下：

• feat: 新增功能
  
• fix: 修复bug
  
• docs: 仅文档更改
  
• style: 不影响代码寄义的更改（空缺、格式设置、缺失 分号等）
  
• refactor: 既不修复bug也不添加特性的代码更改
  
• perf: 改进性能的代码更改
  
• test: 添加缺少的测试或更正现有测试
  
• chore: 对构建过程或辅助工具和库（如文档）的更改
  

除此之外，还有一些常用的范例：

• delete：删除功能或文件
  
• modify：修改功能
  
• build：改变构建流程，新增依赖库、工具等（例如webpack、gulp、npm修改）
  
• test：测试用例的新增、修改
  
• ci：自动化流程配置修改
  
• revert：回滚到上一个版本
  

单次提交留意事项

• 提交问题必须为同一类别
  
• 提交问题不要超过3个
  
• 提交的commit发现不符合规范，git commit --amend -m "新的提交信息"或 git reset --hard HEAD 重新提交一次
  

配置.gitignore文件

.gitignore是一份用于忽略不必提交的文件的列表，项目中可以根据实际需求统一.gitignore文件，减少不必要的文件提交和冲突，净化代码库情况。
通用文件示例：

1. HELP.md
2. target/
3. !.mvn/wrapper/maven-wrapper.jar
4. !**/src/main/**/target/
5. !**/src/test/**/target/
7. ### STS ###
8. .apt_generated
9. .classpath
10. .factorypath
11. .project
12. .settings
13. .springBeans
14. .sts4-cache
16. ### IntelliJ IDEA ###
17. .idea
18. *.iws
19. *.iml
20. *.ipr
22. ### NetBeans ###
23. /nbproject/private/
24. /nbbuild/
25. /dist/
26. /nbdist/
27. /.nb-gradle/
28. build/
29. !**/src/main/**/build/
30. !**/src/test/**/build/
32. ### VS Code ###
33. .vscode/
35. # Log file
36. *.log
37. /logs*
39. # BlueJ files
40. *.ctxt
42. # Mobile Tools for Java (J2ME)
43. .mtj.tmp/
45. # Package Files #
46. *.jar
47. *.war
48. *.ear
49. *.zip
50. *.tar.gz
51. *.rar
52. *.cmd

复制代码

其他

此外，还有一些其他建议：

• master 分支的每一次更新，都建议打 tag 添加标签，通常为对应版本号，便于管理
  
• feature分支、hotfix分支在合并后可以删除，避免分支过多管理杂乱
  
• 每次 pull 代码前，提交本地代码到本地库中，否则可能回出现合并代码出错，导致代码丢失
  

学习书籍及网站

• 保举书籍：
  
  
  
  • Git Pro2英文Github仓库
    
  • Git Pro2中文Gitbook
    
  • Git Pro2对应的中文Markdown版本的仓库地址
    
  • Git Pro中文阅读
    
  
  
• 在线学习
  
  
  
  • git在线学习网站： https://learngitbranching.js.org/
    
  
  

面试题专栏

Java面试题专栏已上线，接待访问。

• 如果你不知道简历怎么写，简历项目不知道怎么包装；
  
• 如果简历中有些内容你不知道该不该写上去；
  
• 如果有些综合性问题你不知道怎么答；
  

那么可以私信我，我会尽我所能帮助你。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4