V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
JustW
V2EX  ›  程序员

Git 奇幻之旅⌛️

  JustW · 312 天前 · 11215 次点击
这是一个创建于 312 天前的主题,其中的信息可能已经有所发展或是发生改变。

第一天: 本地仓库

故事的主角是小明,一个刚入门编程的小白。他正在为一个项目写代码,但是他发现每次修改代码都很麻烦,因为他要不断地备份文件,而且很容易弄混版本。有一天,他听说了一个叫 Git 的神奇工具,可以帮助他管理代码的变化。他决定尝试一下,于是他打开了终端,输入了下面的命令:

git init # 初始化一个本地仓库
git add . # 添加所有文件到暂存区
git commit -m "first commit" # 提交第一次修改到本地仓库

这样,他就成功地创建了一个 Git 仓库,并且保存了他的第一个版本。他觉得很开心,因为这样他就不用担心代码丢失或者混乱了。😁

第二天: 远程仓库

小明觉得自己的代码写得很不错,想要分享给其他人看看。但是他发现把文件发给别人很麻烦,而且如果别人也修改了代码,就很难合并。有一天,他听说了一个叫 GitHub 的网站,可以免费托管 Git 仓库,并且方便和其他人协作。他决定尝试一下,于是他注册了一个 GitHub 账号,并且在网站上创建了一个空的仓库。

然后,他在终端输入了下面的命令:

git remote add origin https://github.com/xiaoming/myproject.git # 添加远程仓库地址
git push -u origin master # 推送本地 master 分支到远程仓库

这样,他就成功地把自己的代码上传到了 GitHub 上,并且和远程仓库建立了联系。他觉得很兴奋,因为这样他就可以和全世界的程序员交流了。😍

第三天: 分支管理

小明在 GitHub 上发现了一个很有趣的开源项目,想要参与其中。但是他不想直接修改别人的代码,而是想先在自己的电脑上做一些改进,然后再提交给项目的作者。有一天,他听说了一个叫分支的概念,可以让他在不影响主线的情况下,创建自己的代码版本。他决定尝试一下,于是他在终端输入了下面的命令:

git clone https://github.com/someone/awesome-project.git # 从远程仓库克隆项目到本地
cd awesome-project # 进入项目目录
git checkout -b dev # 创建并切换到 dev 分支

这样,他就成功地在本地创建了一个 dev 分支,并且和远程仓库的 master 分支分开了。他觉得很自由,因为这样他就可以随心所欲地修改代码了。😎

第四天: 合并与冲突

小明在 dev 分支上修改了一些代码,觉得很满意,想要把自己的改进合并到 master 分支上,然后推送到远程仓库,让项目的作者看看。有一天,他听说了一个叫合并的操作,可以把两个分支的代码合并成一个。他决定尝试一下,于是他在终端输入了下面的命令:

git checkout master # 切换到 master 分支
git merge dev # 合并 dev 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库

这样,他就成功地把自己的代码合并到了 master 分支,并且推送到了远程仓库。他觉得很骄傲,因为这样他就可以为开源项目做出贡献了。😊

但是,有时候合并分支并不是一帆风顺的。有一次,小明在 dev 分支上修改了一个文件,而项目的作者也在 master 分支上修改了同一个文件,并且先于小明推送到了远程仓库。当小明想要合并分支时,就发生了冲突。有一天,他听说了一个叫解决冲突的方法,可以手动选择保留哪些代码。他决定尝试一下,于是他在终端输入了下面的命令:

git pull origin master # 拉取远程仓库的 master 分支
git merge master # 合并 master 分支到 dev 分支
# 打开冲突文件,编辑保存
git add . # 添加所有文件到暂存区
git commit -m "fix conflict" # 提交修改到本地仓库
git push origin dev # 推送 dev 分支到远程仓库

这样,他就成功地解决了冲突,并且把自己的代码推送到了远程仓库。他觉得很成就感,因为这样他就可以和其他人协作了。😄

第五天: 标签管理与忽略文件

小明在 dev 分支上开发了一个新功能,觉得很完美,想要给这个版本打一个标签,方便以后查找。有一天,他听说了一个叫标签的概念,可以给某个版本起一个有意义的名字。他决定尝试一下,于是他在终端输入了下面的命令:

git tag v1.0 # 给当前版本打一个 v1.0 的标签
git push origin v1.0 # 推送标签到远程仓库

这样,他就成功地给自己的代码打了一个标签,并且推送到了远程仓库。他觉得很方便,因为这样他就可以快速定位到某个版本了。😎

但是,有时候有些文件是不需要被 Git 管理的,比如编译生成的临时文件,或者敏感信息的配置文件。有一天,他听说了一个叫忽略特殊文件的方法,可以让 Git 自动忽略掉这些文件。他决定尝试一下,于是他在项目根目录下创建了一个.gitignore 文件,并且写入了下面的内容:

*.tmp # 忽略所有.tmp 后缀的文件
config.ini # 忽略 config.ini 文件

这样,他就成功地让 Git 忽略掉了这些特殊文件,并且不会被提交到仓库中。他觉得很安全,因为这样他就可以避免泄露隐私或者浪费空间了。😊

第六天: 大小写敏感

小明和小红是一个团队的成员,他们都在 GitHub 上为同一个开源项目贡献代码。有一天,小明在本地修改了一个文件的名字,把它从 README.md 改成了 Readme.md ,然后提交并推送到了远程仓库。小红在自己的电脑上拉取了最新的代码,但是她发现自己的文件名还是 README.md ,而且 Git 提示她有一个未合并的文件。她很困惑,不知道为什么会出现这样的情况。

原来,这是因为 Git 在不同的操作系统上对文件名大小写的敏感度不同。在 Linux 和 Mac OS X 上,Git 是区分大小写的,所以 README.mdReadme.md 是两个不同的文件。但是在 Windows 上,Git 是不区分大小写的,所以 README.mdReadme.md 是同一个文件。当小明把文件名改成了 Readme.md 时,Git 认为他删除了 README.md ,并且创建了一个新的文件 Readme.md 。当小红拉取代码时,Git 认为她需要合并这两个文件,所以出现了冲突。

有一天,他们听说了一个叫解决大小写不一致导致的合并冲突的方法,可以让 Git 在 Windows 上也区分大小写。他们决定尝试一下,于是他们在终端输入了下面的命令:

git config core.ignorecase false # 设置 Git 在 Windows 上也区分大小写
git mv README.md Readme.md # 重命名文件
git commit -m "rename file" # 提交修改
git push origin master # 推送到远程仓库

这样,他们就成功地解决了大小写不一致导致的合并冲突,并且保持了文件名的一致性。他们觉得很开心,因为这样他们就可以避免以后出现同样的问题了。😁

第七天: 撤销错误提交与恢复误删文件

小明和小红在开发一个新功能时,不小心提交了一些错误的代码,导致项目无法运行。他们想要撤销这些提交,但是又不想丢失他们的修改。有一天,他们听说了一个叫 reset 的命令,可以让他们回退到某个版本,但是保留他们的修改。他们决定尝试一下,于是他们在终端输入了下面的命令:

git reset HEAD~2 # 回退到两个版本之前,保留修改
git status # 查看修改的状态
git add . # 重新添加修改到暂存区
git commit -m "fix bug" # 重新提交修改
git push -f origin master # 强制推送到远程仓库

这样,他们就成功地撤销了错误的提交,并且重新提交了正确的代码。他们觉得很轻松,因为这样他们就可以修复 bug 了。😊

但是,有时候 reset 命令也会带来麻烦。有一次,小明在回退版本时,不小心加了一个–hard 选项,导致他的修改全部丢失了。他很慌张,不知道如何找回他的修改。有一天,他听说了一个叫 reflog 的命令,可以让他查看所有的提交历史,包括已经被删除或者回退的提交。他决定尝试一下,于是他在终端输入了下面的命令:

git reflog # 查看所有的提交历史
git reset --hard c761f5c # 回退到指定的版本
git status # 查看修改的状态

这样,他就成功地找回了他丢失的修改,并且恢复到了正确的版本。他觉得很幸运,因为这样他就可以继续开发了。😄

第八天: 多人协作与冲突处理

小明和小红在同一个分支上开发一个新功能,他们经常需要拉取对方的代码,然后合并到自己的代码中。有一天,他们听说了一个叫 pull 的命令,可以让他们一步完成拉取和合并的操作。他们决定尝试一下,于是他们在终端输入了下面的命令:

git pull origin master # 拉取并合并远程仓库的 master 分支

这样,他们就成功地把对方的代码合并到了自己的代码中,并且保持了同步。他们觉得很方便,因为这样他们就可以避免手动合并的麻烦了。😎

但是,有时候 pull 命令也会带来问题。有一次,小明和小红在同一个文件上修改了同一行代码,导致出现了冲突。他们很困惑,不知道如何解决这个冲突。有一天,他们听说了一个叫解决冲突的方法,可以让他们手动选择保留哪些代码。他们决定尝试一下,于是他们在终端输入了下面的命令:

git pull origin master # 拉取并合并远程仓库的 master 分支
# 打开冲突文件,编辑保存
git add . # 添加所有文件到暂存区
git commit -m "merge conflict" # 提交修改到本地仓库
git push origin master # 推送到远程仓库

这样,他们就成功地解决了冲突,并且把自己的代码推送到了远程仓库。他们觉得很成就感,因为这样他们就可以和对方协作了。😄

第九天: rebase 和 merge 的区别

小明和小红在同一个项目上开发不同的功能,他们分别在自己的分支上提交了一些代码。有一天,他们想要把自己的代码合并到主分支上,但是他们不知道应该用 rebase 还是 merge 。有一天,他们听说了一个叫 rebase 和 merge 的区别的概念,可以让他们选择合适的方式来合并代码。他们决定尝试一下,于是他们在终端输入了下面的命令:

# 小明在 dev1 分支上
git checkout dev1 # 切换到 dev1 分支
git rebase master # 把 dev1 分支变基到 master 分支
git push -f origin dev1 # 强制推送 dev1 分支到远程仓库
git checkout master # 切换到 master 分支
git merge dev1 # 合并 dev1 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库

# 小红在 dev2 分支上
git checkout dev2 # 切换到 dev2 分支
git merge master # 合并 master 分支到 dev2 分支
git push origin dev2 # 推送 dev2 分支到远程仓库
git checkout master # 切换到 master 分支
git merge dev2 # 合并 dev2 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库

这样,他们就成功地把自己的代码合并到了主分支上,但是他们发现了一个不同的地方。小明用了 rebase 命令,他的提交历史是一条直线,没有任何分叉;小红用了 merge 命令,她的提交历史是有多个分叉和汇合的结构。他们觉得很好奇,不知道这两种方式有什么优缺点。

原来,rebase 和 merge 的区别是:

  • rebase 是把自己的分支变基到目标分支上,也就是把自己的提交历史放在目标分支的最后,这样可以保持提交历史的整洁和线性。
  • merge 是把目标分支合并到自己的分支上,也就是把目标分支的提交历史和自己的提交历史合并成一个新的提交,这样可以保持提交历史的完整和真实。

rebase 和 merge 各有优缺点:

  • rebase 的优点是可以让提交历史看起来很简洁,方便查看和管理;缺点是会改变提交历史,可能导致冲突或者丢失信息。
  • merge 的优点是可以保留提交历史的原貌,方便追溯和恢复;缺点是会让提交历史看起来很复杂,不容易理解和维护。

所以,在选择 rebase 还是 merge 时,要根据具体的情况和需求来决定。一般来说:

  • 如果你想要保持一个干净和线性的提交历史,你可以用 rebase ;
  • 如果你想要保留一个完整和真实的提交历史,你可以用 merge ;
  • 如果你想要在公共的分支上合作,你应该用 merge ,避免用 rebase ,因为 rebase 会改变提交历史,可能导致其他人的困扰;
  • 如果你想要在私有的分支上开发,你可以用 rebase ,因为 rebase 可以让你的提交历史更清晰,方便你自己管理。

第十天: 撤销错误合并和恢复误删的分支

小明和小红在合并分支时,不小心合并了错误的分支,导致项目出现了很多 bug 。他们想要撤销这次合并,但是又不想丢失他们的修改。有一天,他们听说了一个叫 revert 的命令,可以让他们用一次新的提交来回滚之前的提交。他们决定尝试一下,于是他们在终端输入了下面的命令:

git log # 查看提交历史
git revert <commit ID> # 回滚指定的提交
git push origin master # 推送到远程仓库

这样,他们就成功地撤销了错误的合并,并且用一次新的提交来记录这次回滚。他们觉得很安全,因为这样他们就不会丢失任何修改了。😊

但是,有时候 revert 命令也会带来麻烦。有一次,小明在回滚一个合并时,不小心加了一个–no-commit 选项,导致他的修改没有被提交,而是被放在了暂存区。他很慌张,不知道如何恢复这次回滚。有一天,他听说了一个叫 reset 的命令,可以让他回退到某个版本,并且保留或者丢弃他的修改。他决定尝试一下,于是他在终端输入了下面的命令:

git reset --soft HEAD^ # 回退到上一个版本,并且保留修改
git status # 查看修改的状态
git add . # 重新添加修改到暂存区
git commit -m "fix bug" # 重新提交修改
git push -f origin master # 强制推送到远程仓库

这样,他就成功地恢复了这次回滚,并且重新提交了正确的代码。他觉得很轻松,因为这样他就可以修复 bug 了。😊

第十一天: 删除和恢复分支

小明和小红在完成一个功能后,想要删除自己的分支,因为他们觉得这个分支已经没有用了。有一天,他们听说了一个叫 delete 的命令,可以让他们删除本地或者远程的分支。他们决定尝试一下,于是他们在终端输入了下面的命令:

git branch -d dev1 # 删除本地的 dev1 分支
git push origin --delete dev1 # 删除远程的 dev1 分支

这样,他们就成功地删除了自己的分支,并且释放了一些空间。他们觉得很爽快,因为这样他们就可以开始新的功能了。😎

但是,有时候 delete 命令也会带来后悔。有一次,小明在删除一个分支后,发现自己还需要这个分支上的一些代码。他很懊恼,不知道如何找回这个分支。有一天,他听说了一个叫 reflog 的命令,可以让他查看所有的提交历史,包括已经被删除或者回退的提交。他决定尝试一下,于是他在终端输入了下面的命令:

git reflog # 查看所有的提交历史
git checkout -b dev1 <commit ID> # 用指定的提交创建一个新的 dev1 分支
git push origin dev1 # 推送 dev1 分支到远程仓库

这样,他就成功地找回了自己的分支,并且恢复到了正确的版本。他觉得很幸运,因为这样他就可以继续使用这个分支了。😄

最后

到此为止,我已经给你讲完了小明和小红的故事,你觉得怎么样?👏

第 1 条附言  ·  312 天前
92 条回复    2023-06-26 13:44:21 +08:00
mineralsalt
    1
mineralsalt  
   312 天前   ❤️ 35
懂得人不会看, 不会的人看不懂
GTim
    2
GTim  
   312 天前   ❤️ 3
其实还是蛮有用的
Victor215
    3
Victor215  
   312 天前   ❤️ 1
git 个人感觉还是要 GUI 操作,啥撤销恢复啥的的命令根本记不住。
JustW
    4
JustW  
OP
   312 天前
@mineralsalt 哈哈,适合刚入门的看一下大体的使用流程.
JustW
    5
JustW  
OP
   312 天前   ❤️ 1
@GTim 主要是自己梳理下流程,日常操作应该够用了.
JustW
    6
JustW  
OP
   312 天前
@Victor215 是的,我一般也是用 IDEA 带的插件操作.记住一些常用的就行.
HankLu
    7
HankLu  
   312 天前   ❤️ 6
@mineralsalt 胡扯,这对似懂非懂的人非常有用,感谢楼主的帖子,收藏了。
someonesnone
    8
someonesnone  
   312 天前 via iPhone
有跟乌龟一样的图形界面吗 记不住命令行
wjx0912
    9
wjx0912  
   312 天前
弱弱的提个 bug:
git push -u origin master
--->
git push -u origin main
russ44
    10
russ44  
   312 天前
cool
xiangyuecn
    11
xiangyuecn  
   312 天前   ❤️ 1
@someonesnone #8
@Victor215 #3

TortoiseGit ,Windows 专享
Liuman
    12
Liuman  
   312 天前
学习了,谢谢
fishworm
    13
fishworm  
   312 天前
写的不错,支持一下。
wsssss
    14
wsssss  
   312 天前
从来不用 git push -f 感觉强推太危险。我 rebase 时都是单拉分支再 push 。
ruanimal
    15
ruanimal  
   312 天前   ❤️ 1
@wjx0912 这个不算 bug 吧,main 分支是政治正确的邪教
zhhqiang
    16
zhhqiang  
   312 天前
给 解决 windows 区分 大小写 点赞,之前都是删了重新提交。
ql562482472
    17
ql562482472  
   312 天前   ❤️ 1
@someonesnone #8 有 看命令行的都是大神 我们小白还是 UI 把 Idea 那种简洁 UI 就是最简单的
season8
    18
season8  
   312 天前
挺好的,配合应用场景,特别适合入门和囫囵吞枣的
ztc
    19
ztc  
   312 天前
👍🏻
november
    20
november  
   312 天前
虽然但是,mac os 默认也是不区分大小写的。这估计又是哪里复制黏贴的。
mingsi
    21
mingsi  
   312 天前 via Android
可能是我见识短,这是我见过的最好的中文 git 入门简介了!
miaotaizi
    22
miaotaizi  
   312 天前
小明跟小红最后在一起了吗?

第二季什么时候出?
zoezz
    23
zoezz  
   312 天前
不错👏
keepro
    24
keepro  
   312 天前
对于我来说,我还是挺喜欢这种教程的,在熟悉的过程中,再看详细的命令介绍,会有很大的进步。感谢分享~
we21x
    25
we21x  
   312 天前
补充一个 git stash 指令:
小明在本地开发一个新功能的时候需要修改本地的配置文件,但是这个修改只能保存在本地,而且每次开发新功能的时候都需要修改本地的配置文件。小明不想每次都手动修改配置文件,有一天小红告诉他一个叫 stash 的指令,可以将本地的修改丢弃并保存在 git 中,然后通过 git stash pop 恢复最近一次的修改、git stash apply <idx> 恢复某一次修改的内容,这样小明就无需每次都手动修改配置文件了,他觉得很开心( doge ;另外这个指令切分支的时候也很有用~
placeholder
    26
placeholder  
   312 天前
写的很好,抄走…不是…收藏了
remember5
    27
remember5  
   312 天前   ❤️ 1
wayne3602
    28
wayne3602  
   312 天前 via Android
现在一般都是 main 分支了吧,建议改一下
Hanser002
    29
Hanser002  
   312 天前
@wjx0912 异端
JustW
    30
JustW  
OP
   312 天前
@wayne3602 是的.不过 v2 上好像不能重新编辑了.我改下我原文的.哈哈
Baoni
    31
Baoni  
   312 天前
谢谢,最近有不会的操作都在问 gpt 了
daimubai
    32
daimubai  
   312 天前
@wjx0912 github 是可以修改 main 为 master 的,像公司一般搭建 git 的话也还是 master 。而且 git 本身的主分支就是 master
JustW
    33
JustW  
OP
   312 天前   ❤️ 1
@someonesnone 有的,很多.我一般用的 idea 自带的.或者是 GitKraken 这款也行.
JustW
    34
JustW  
OP
   312 天前
@miaotaizi 等学完了就在一起了.QAQ
xiaojianghu
    35
xiaojianghu  
   312 天前
“如果你想要在公共的分支上合作,你应该用 merge ,避免用 rebase ,因为 rebase 会改变提交历史,可能导致其他人的困扰”,rebase 真的会给别人带来困扰吗
magicls
    36
magicls  
   312 天前
支持一下,个人觉得其实写得挺好的。
baiyi
    37
baiyi  
   312 天前
对刚接触的人来说还是挺不错的,结合了场景来教命令。对于想要深入一点学习 git 的人来说,推荐 《 Pro Git 》
JustW
    38
JustW  
OP
   312 天前
@xiaojianghu 这块主要针对多人开发时,可能会因为历史顺序的变动,导致其他人更新时需要额外了解.merge 的话,每个人提交记录更清晰.
JustW
    39
JustW  
OP
   312 天前
@baiyi 哈哈.这个我博客里还有一篇深入点的笔记,以及参考的几个比较好的 git 的学习站点.
wellerman
    40
wellerman  
   312 天前
挺好,总结的不错。
mrzx
    41
mrzx  
   312 天前
写的非常好
ooops
    42
ooops  
   312 天前
@wsssss --force-with-lease
xiaojianghu
    43
xiaojianghu  
   312 天前   ❤️ 1
@JustW #38 我在工作中更多的使用 rebase ,我感觉 rebase 的提交就像直接在主分支上提交的一样,看不出来是否开了一个新分支并将提交合到主分支,merge 可以看到这个过程,所以 rebase 更容易产生冲突吗
AlexBirmingham
    44
AlexBirmingham  
   312 天前
@wjx0912 ??我学习的是 GUI 的默认是 main ,git 默认是 master 。 博主就是练习命令行操作,master 没有错啊,main 才不对
xabcstack
    45
xabcstack  
   312 天前
git pull && git push 梭哈,其他都是浮云
zq11211277
    46
zq11211277  
   312 天前
@mineralsalt #1 哈哈 说的没错 适合二懂二懂的看
JustW
    47
JustW  
OP
   312 天前
@xiaojianghu 这块我不知道怎么表达,大概就是个人开发的话,用 rebase 可以让自己看历史记录更清晰,但是当合并主分支的时候,用 merge 让其他人看起来跟清晰, 最后还是看个人使用习惯吧.并没有说哪种就不行.哈哈. 另外冲突实际上两种方式都会出现.
JustW
    48
JustW  
OP
   312 天前
@xiaojianghu 可以看下这个网站的讲解,比我写的更加深刻,全面!https://www.atlassian.com/git/tutorials/merging-vs-rebasing
xiaojianghu
    49
xiaojianghu  
   312 天前
@JustW #48 好的,感谢
bojackhorseman
    50
bojackhorseman  
   312 天前
提到大小写敏感,如果你直接把 `user.vue` 改成 `User.vue`, git 默认会认为没变化,但你本地的编辑器会感知到,于是你修改了文件引入,但推到线上别人一拉,发现文件名还是小写的,编译失败,文件引入找不到🤣。
我有一个文件名改大小写的小妙招,先把文件名改成别的,再改大写就可以了:

git mv user.vue userA.vue

git mv userA.vue User.vue
jackshen
    51
jackshen  
   312 天前
赞👍 又 get 到了一些新技巧
lasuar
    52
lasuar  
   312 天前
多年开发,对于 git 也只是熟悉常用指令,看了楼主的文字后终于熟悉了 rebase 、reflog ,非常感谢啊~~~
wangqiKylin
    53
wangqiKylin  
   312 天前
不错,给 op 点个赞,先马再看
fox233
    54
fox233  
   312 天前
新版本 Git 切换分支是 git switch
nullpoint007
    55
nullpoint007  
   312 天前
收藏
bzsh
    56
bzsh  
   312 天前
@wjx0912 哈哈哈,想起这个 master 就想笑
MRG0
    57
MRG0  
   312 天前   ❤️ 1
@someonesnone Git Extensions
zhengkk
    58
zhengkk  
   312 天前
简单问题复杂化
pkoukk
    59
pkoukk  
   312 天前
挺好的,但是对小白我都直接推荐 GUI
JustW
    60
JustW  
OP
   312 天前
@pkoukk 是的,现在一般都用的 GUI,这个文章也就是让大家了解下有这么个命令,真要研究,肯定还要找别的资料学习的.
Vclow
    61
Vclow  
   312 天前
GUI 还是方便很多,偶尔用命令
wayne3602
    63
wayne3602  
   312 天前
@JustW #30 文章我偷走了,存到我的笔记里哈哈
Margelator
    64
Margelator  
   312 天前
不会的人直接卡在第一步
Cursor1st
    65
Cursor1st  
   312 天前
学到了学到了,很不错,感谢
justin2018
    66
justin2018  
   312 天前
以前只会 git add . ---> git commit "xxxxxx" ---> git push

后来项目中遇到各种需求 就学会了 更多的技能 😁
Biluesgakki
    67
Biluesgakki  
   312 天前
我还是喜欢用命令 。另外可以加一个 git commit --amend
JustW
    68
JustW  
OP
   312 天前
@justin2018 哈哈,我也是,经常用的也就这几个,加上合并
JustW
    69
JustW  
OP
   312 天前
@Biluesgakki 这个命令在我博客的另外一篇文章里有写,
hitmanx
    70
hitmanx  
   312 天前
支持一下,谢谢分享
huitailangcy
    71
huitailangcy  
   312 天前
牛逼,感谢分享
7gugu
    72
7gugu  
   312 天前
感觉还是得靠实践才记得住😂,不过 OP 的分享很有用👍
XxxxD
    73
XxxxD  
   312 天前
很不错,感谢分享,之前看过 progit 太详细了,你写的很形象很好记忆
lingalonely
    74
lingalonely  
   312 天前
挺好的,基本可以覆盖 80 ~ 90%的使用场景,就有些特殊情况没提及 比如 stash 的情况
leeton
    75
leeton  
   312 天前 via iPhone
我自始至终就会一个命令,就是 git clone 。其余的都是用 idea 提交的,手比较残🥲
TomPig0216
    76
TomPig0216  
   312 天前
感谢分享哈哈 温故而知新了属于是
hhjswf
    77
hhjswf  
   312 天前 via Android
话说,按照你的解释,rebase 和 merge 根本不是一回事啊没什么好比较的。rebase 是变基,最后合并还是用 merge 。
hhjswf
    78
hhjswf  
   312 天前 via Android
@xiaojianghu 你这样为什么不直接在主分支上开发提交?
WisdomDevil
    79
WisdomDevil  
   312 天前 via Android
谢谢楼主用简明的方式解释~
liberty1900
    80
liberty1900  
   312 天前
现在的年轻人,第 6 天就碰上大小写敏感问题,第 9 天就开始 rebase 啦

何时学习 git push -f 捏
liberty1900
    81
liberty1900  
   312 天前
@liberty1900 好吧,第 7 天就有了
jqtmviyu
    82
jqtmviyu  
   311 天前
补充下 非快速合并和默认的快速合并

git merge --no-ff

https://i.loli.net/2021/09/23/FCOl2vwHo1qxPMu.png
Eliven
    84
Eliven  
   311 天前
JustW
    85
JustW  
OP
   311 天前
@Eliven 是的,配套使用,这个网站我也用过.
Aaron01
    86
Aaron01  
   311 天前 via Android
太好了
shaozelin030405
    87
shaozelin030405  
   311 天前
自己用 gui 搞。。。好伐
yuanxin1999
    88
yuanxin1999  
   311 天前
@wjx0912
想到了 Yandex 的 master 和 nigger😂
Vanderick
    89
Vanderick  
   311 天前
写得挺好的~ 赞
xiaojianghu
    90
xiaojianghu  
   311 天前
@hhjswf #78 习惯了开新分支修 bug 或写需求
Meonardo
    91
Meonardo  
   309 天前 via iPhone
🇰🇷🇰🇷🇰🇷
qqqyh
    92
qqqyh  
   299 天前
第一次知道 windows 上 git 不区分大小写
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1115 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 23:38 · PVG 07:38 · LAX 16:38 · JFK 19:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.