你说的这个就是好处啊，重新copy一份确实也可以，不过代码比较复杂的时候这样搞会很乱，试验成功了合并回来也很麻烦吧。
另外commit也是有很重大意义的。阶段性通过之后commit是一种工作方式，commit之后才方便用diff看最近都做了什么，方便自己看看是不是还有哪里不妥？是不是有测试代码没删除？是不是有试验性调整没改回来？我不知道你看不看，我反正每次commit之前都会diff过一次的，所以如果我是一个经常无法正常联网commit的人，我会考虑用git
【 在 webhost 的大作中提到: 】
: 到底体现出啥好处呀？ Commit提交到本地跟我代码，直接放在本地不动有啥区别？
: Get不依赖于远程服务器的唯一用途，我就是拿来当备份用的，有时候想实现另外一套思路试试看，就开个分支，一旦试错不成功，就直接废弃掉行了。然而也仅此而已，跟我把源代码目录copy一份拿来干活也没啥本质区别。
--
FROM 14.155.115.*

git这个分布式对开源软件的协作是非常有用的。你可以clone别人的代码到本地，可以
自己本地修改，本地提交，也可以跟踪别人的仓库。但是想push到别人的仓库，默认是
不可以的。

如果开源软件用svn，你checkout一份代码出来，是没法直接commit到中心库的，你的修
改要commit，那么就只能自己建立一个中心仓库，这是很不方便的。

总之和断网没一毛钱关系，现在是2022年，工作环境几乎不可能长期没有网络。


【 在 b0207191 的大作中提到: 】
: 集中式（SVN）和分布式（Git）版本控制系统的简单比较 - Raychan - 博客园 (cnblogs.com)
: 看了上面文章，结合目前所在项目开发现状，有些疑问
: 没有中央服务器，开发人员本地都有 Local Repository
: ...................
--
FROM 222.90.31.*

能在断网环境使用还是很有用的。
我曾经去客户那里联调，一连好几天，上网很不方便。
每调通一部分，就希望commit一版，保存当前成果。

还有一次也是在现场，某项测试总是不过。我们家里又没有相关测试环境，因此提前在家里针对每一种可能的因素，制定了一个版本，就是在主干上建了一个分支。到了现场，在不同的分支上切换，对于某些有希望通过测试的分支，再加以改进。

这种环境下，git这种不需要中心库的特性非常好用。

【 在 spadger 的大作中提到: 】
: git这个分布式对开源软件的协作是非常有用的。你可以clone别人的代码到本地，可以
: 自己本地修改，本地提交，也可以跟踪别人的仓库。但是想push到别人的仓库，默认是
: 不可以的。
: ...................
--
FROM 59.109.148.*

举一个不算特别复杂的场景
项目中三组人，每组人也不用太多，一组在开发A功能，一组在开发B功能，还有一组随时有可能修复线上bug ，copy 一份出来 怎么干活，最后怎么合并？大家都有可能修改公共代码
【 在 webhost 的大作中提到: 】
: 到底体现出啥好处呀？ Commit提交到本地跟我代码，直接放在本地不动有啥区别？
: Get不依赖于远程服务器的唯一用途，我就是拿来当备份用的，有时候想实现另外一套思路试试看，就开个分支，一旦试错不成功，就直接废弃掉行了。然而也仅此而已，跟我把源代码目录copy一份拿来干活也没啥本质区别。
--
FROM 61.51.238.*

bcomp的目录对比功能很好用，完成你说的功能毫无问题。


【 在 hanger 的大作中提到: 】
: 举一个不算特别复杂的场景
: 项目中三组人，每组人也不用太多，一组在开发A功能，一组在开发B功能，还有一组随时有可能修复线上bug ，copy 一份出来 怎么干活，最后怎么合并？大家都有可能修改公共代码
--
FROM 222.90.31.*