msg7086's repos on GitHub
Assembly · 174 人关注
x265-Yuuki-Asuna
A fork of x265. A modded version.
Ruby · 13 人关注
rb1drv
msg7086's Ruby SDK for Microsoft OneDrive Service
C · 10 人关注
bs4kass
C++ · 7 人关注
gop_muxer
Assembly · 6 人关注
x265
An unofficial mirror to x265 repository, using hg-git. Since MCW switched to Git in 2020, this mirror no longer serves its purpose and has stopped mirroring.
C · 5 人关注
koying-bdtools
forked from koying/bdtools
C++ · 4 人关注
aac-channel-splitter
C · 4 人关注
x264_tMod
tMod: patched x264, dangerous
Ruby · 3 人关注
nails
Create thumbnails for video clips.
C++ · 2 人关注
latm-channel-splitter
C++ · 1 人关注
avs2avi
PHP · 1 人关注
popro
popro
Ruby · 1 人关注
rb1drv-tools
C · 1 人关注
VapourSynth-Bilateral
Bilateral filter for VapourSynth.
C++ · 1 人关注
VSFilterSimpleMod
DON'T USE THIS
0 人关注
CorvallisTour
The Corvallis Tour application is an accompanying mobile website for a guided tour in Corvallis.
C · 0 人关注
ffmpeg-24ch-patch
C · 0 人关注
l-smash
L-SMASH's official repo
Python · 0 人关注
MyECTools
Some functions ported from MyEPTools
C# · 0 人关注
No-Industries-Import
Ruby · 0 人关注
opensearch
drawnboy's opensearch gem patched for SSL support.
Ruby · 0 人关注
rabbitdns
Rabbit DNS
C · 0 人关注
repcached
0 人关注
RoomReservation
OSU Libraries & Press Room Reservation System
Ruby · 0 人关注
ruby-bbcode
Convert BBCode to HTML and check whether the BBCode is valid
Ruby · 0 人关注
ruby-bencode
Ruby bindings for the bencode data serialization format
Ruby · 0 人关注
rubycas-client
Ruby client for Yale's Central Authentication Service protocol -- an open source enterprise single sign on system for web applications.
C# · 0 人关注
starsub
Automatically exported from code.google.com/p/starsub
C · 0 人关注
VapourSynth-Retinex
Retinex algorithm for VapourSynth
msg7086

msg7086

🏢  Software Engineer
V2EX 第 38436 号会员,加入于 2013-05-04 05:31:44 +08:00
今日活跃度排名 5487
根据 msg7086 的设置,主题列表只有在你登录之后才可查看
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
msg7086 最近回复了
@cloudyrs 几年前的事儿了。
@Admstor 毕竟多删一个号就多一个卖 VIP 的机会啊。
曾经我也有 mt 。
42 天没登录,号就没了。
靠谱盘基本都是大容量企业级。就算对容量没需求也可以考虑买大硬盘。
就跟,开汽车了会不会降低驾驭马车的能力一样。
用高级语言一样会降低你写 C 和汇编的能力的。
5 天前
回复了 hanxu317138 创建的主题 git git rebase 那么重要么???
(续)
总之 git 本身也不是一本史书,git 是一个 Source code management ,这个软件的核心目的是管理源代码,最终这个管理是要为软件开发和发布服务的,对软件开发和软件发布有益的做法就是正确的做法,如果一种做法导致软件开发变得困难,这种做法就应该被认定为是不合适的。如果提交历史一团糟,这个一团糟到底是改善了软件开发环境,还是影响了软件开发环境,你这样去判断,就能知道保留一团糟的历史是否是一件正确的事情。不要为了准确而准确,为了记录而记录,这是一个软件开发工具,不是史书编撰工具。
5 天前
回复了 hanxu317138 创建的主题 git git rebase 那么重要么???
@dcsuibian #19
这两种观点并不是完全冲突的。
保留历史的细节程度和历史的尺度有关。比如说你遇到了生产事故,需要写事故处理记录,你当然要把每一分每一秒每一次事件都记录下来。但如果你是在写上下五千年的史书,那会有人关心你某一天下午 2 点的时候打翻了一杯水吗。
我司在开发的比较大的项目,尺度基本是上下十年,一个工程师一个月交两个功能,一个 team 下 50 个人一个月就是 100 个功能,一年 1200 个,十年 12000 个,假如平均实现一个功能有 10 个提交,那就是 12 万个提交,你光是要查两三个月前某个提交的 bug 就得翻不知道多少页才能找到,就非常不方便。这还是 master 分支,你要再加上 release 分支测试分支就更多了。所以我们要求所有合并到主线的提交都是 squash merge 。开发分支提 PR 的时候随便你多少个提交,最后全合一起。
如果是小项目,比如说 one man 项目或者一个 team 里两三个人协作,那可以把提交做得细一点,合并 feature 分支的时候用 merge commit 就没问题。

记录实际发生过什么这个也是有粒度的。严格来讲,每一次输入删除都是一次更改,但你肯定不会觉得每打一个单词都要提交吧。那么到底打多少个单词才需要提交一次呢,删了多少代码才需要提交一次呢。这个粒度把控,不同的人也有不同的观点的。
5 天前
回复了 hanxu317138 创建的主题 git git rebase 那么重要么???
先 squash 再 rebase 再 merge 就行。
每一个操作都有自己该用和不该用的场景,正确的做法是在正确的场景用正确的操作。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4808 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 15ms · UTC 09:10 · PVG 17:10 · LAX 01:10 · JFK 04:10
Developed with CodeLauncher
♥ Do have faith in what you're doing.