我上传了一个 Git 简明教程

[L2Sddiw]

github | gitbook

希望能给有需要的人一些帮助

优势

• 只局限于 Git ，全本地操作，使用很简单的例子介绍并使用 Git；
• 按照实验自行动手，可以很轻松的明白 Git 的操作流程；

缺点

• 只局限于 Git ，对于实际工作流和操作还未更新。
• 常用的图形化软件以及外部仓库（Github\GitLab 等）还未更新。

[ateist]

挺好, 收藏了

[fresco]

一直都没系统的学习一下 赞一个

[TFTree]

收藏了

[IamCyborg]

可以 收藏了

[723X]

谢谢大兄弟，正好需要！

[awinds]

收藏了

[lwjef]

补充个 猴子都能懂的 git 入门
https://backlog.com/git-tutorial/cn/

[elmagnificogg]

补充一个我 15 年的 blog
https://elmagnifico.tech/2015/11/03/Git-Auto/

[topqrh]

感谢，先收藏😁

[Hliushi]

谢谢啦，已经收藏了

[SenLief]

收藏，希望大佬能更新写一下工作流，主要是 github 贡献工作流以及工作常用的工作流。

[SJH0402]

感谢，已收藏

[iyobucuo]

感谢分享！！

[Trello]

同楼上，希望可以补充下工作流，已收藏 Star 。

[PrtScScrLk]

写得很好，赞一个。

[ZestZhang01]

写得不如廖雪峰，有点重复造轮子的感觉(如果后面写的经验很实用且廖的教程里也没有就无视这段话)

[ivvei]

看了几章，感觉意义不大。我觉得现阶段类似的教程已经很多了，你要么就把问题讲透，要么不如不写。我看到 git add 重复操作那里，这段我是感觉什么都没讲明白，甚至答非所问。

“具体来说，在实验中，我们使用 git add 命令告诉 Git 开始跟踪一个新的文件，并记录其当前状态。然后我们对该文件进行修改并提交更改，这将创建一个新的 Git 提交记录。这个提交会让 Git 检测所有文件的变化，并记录这些变化 ，这样，Git 能够跟踪整个代码库的演变历史，而不是仅仅跟踪单个文件的更改历史。”

这段你仔细想想，说的是对的吗？按照你这个描述，那得先 git add ， 再修改， 再 git commit （恰好是一般人所想要的步骤）。 而事实上是先修改，再 git add ， 再 git commit 。

[xx3122]

谢谢

[quejuwen]

我也推荐一个： https://tobebetterjavaer.com/git/git-qiyuan.html

[belain]

只要是 git 的教程都点赞

[xsephiroth]

“什么时候使用 rebase ？不用最好”

这是个非常误导人的做法

[L2Sddiw]

@ivvei 感谢你的回复，我可能没有描述清楚。
1. 我这里描述的问题是，“我添加了一个新文件，需要使用 git add 去添加追踪状态，修改文件后为什么还需要使用此命令？” 按照常理，文件已经被系统接管，文件的状态会被识别，大可不必再次重复操作。但 Git 的设计思想是针对整个代码库的，而不是针对文件，从而需要更精细的控制，也就是使用者告诉 Git 我该怎么处理这个文件。

2. 你列举那一段，我描述的是针对新文件，需要先使用 git add 追踪文件 --> 修改文件 --> git add 暂存 --> git commit 暂存

[L2Sddiw]

@L2Sddiw 打错字了

2. 你列举那一段，我描述的是针对新文件，需要先使用 git add 追踪文件 --> 修改文件 --> git add 暂存 --> git commit 提交

[L2Sddiw]

@xsephiroth 团队开发中，rebase 会直接改变整个提交历史

[xiebruce]

我之前也写过一篇文章： https://www.xiebruce.top/1780.html ，基于 macOS

[iorilu]

git 教程最好得是这个把

https://learngitbranching.js.org/

[google2023]

上传到哪里去了？

[bigdaxin]

超级感谢！毫不犹豫 star

[xqcode]

不错

[zzzsy]

建议用 git restore

[ivvei]

@L2Sddiw 不是啊，我贴的是原文啊。 “然后我们对该文件进行修改并提交更改” 这里哪有暂存的一步？另外实践中你第一步修改前的 git add 是需要的吗？不需要啊。

此外为什么针对代码库就得先修改再 add ？这是什么道理？