好的Git教程?科研日常&团队合作,该如何keep track?

本人PhD在读,非CS专业,但是日常使用MATLAB。因为身边没有业界码农朋友,想向各位请教(伸手)一下优秀的Git实战教学视频,付费与否不介意,只求能学到实用的Git案例和最佳应对方案。

这个网站我刷了两遍,每一道题都重新敲了两遍+,但是对于日常使用Git还是有很多的困惑:

目前的主要困惑就是(想到哪里就写到哪里,没有什么逻辑顺序):

  1. 是不是业界的Git Manager不喜欢使用rebase指令向已有的代码中添加新的feature,而只允许merge?我上面刷的这个网站作者喜欢用rebase,于是我现在只倾向于rebase。
  2. 我的习惯是每次MATLAB代码有新的改动时,给file name加一些后缀,然后save as一个新的file。这样的习惯对于Git是不是暴殄天物?我的意思是,Git的version control可以很好的还原某次改动的那个版本,所以我不需要建立n个名字类似的.m文件来备份。但是我不知道最正确的version control怎么操作,也害怕自己Git水平不够导致自己不能replicate结果。
  3. 在每次commit时,message应该按照怎样的书写规范,才能帮助自己在日后快速翻到需要的关键字?
  4. git tags 的使用频率应该是什么样子?我的意思是,是在完成了某个版本的所有修改时,是把tags当作一种version control,还是修改到一半,但是有重大修改时,使用git tags?
  5. MATLAB科研时,日常git push应该是怎样的频率呢?我经常因为懒得push而忘记前些天的修改,也经常因为懒得写commit -m的内容,导致日后翻看commit查找不到需要的内容。业界的日常git是怎样的频率?是finalize一个feature change才会push吗?如果需要一个科研日记本,应该是怎样使用git?
  6. 目前在和实验室另外一个人合作一个项目,但是我还是很糊涂,如果我们同时修改了同一个代码,应该是怎么样的操作步骤,才能保证remote repo和我们每个人的repo不会发生错乱?我们有fork master,但是真的merge俩人的同一个修改到master上,我还是有点犯怵。

目前想到的问题就这些,我的git水平很低,也没有CS的同事氛围和背景,所以如果大家懒得解释太多,直接甩给我学习资料的link就可以。谢谢!

@physixfan 学术版需求来了:joy:

哈哈哈 先看看需求大不大吧 目前先放在闲聊就好 相关帖子很多的话就建个板块~

物理粉居然在线秒回!哈哈。想知道物理粉是怎么keep track自己的code的~

:thinking: 我和别人协作都直接push到master的,可能是最坏practice了

就用用简单的github基础功能 毕竟学术代码普遍结构不复杂:joy: 我也没有那种比较正规的多人合作 基本都是自己的代码自己弄所以github上的记录乱一点也没事…

开个玩笑

git 三法宝难道不是 git reset --hardgit merge -X oursgit push --force

当年年少无知,生产项目三部曲一搞,差点工作没了

1赞

2是肯定不对的,version control下完全不应该用后缀的方式
5的话,我觉得commit比较重要,push不push倒是问题没那么大,毕竟commit完了那改动的记录就不会丢了。

我最早用的时候看过这个 https://www.liaoxuefeng.com/wiki/896043488029600
不过说实话,现在在读OMSCS,同学里基础的git都不会的满地都是。。。所以都是慢慢学慢慢用哒
其实你担心的很多事情都可以自己实验。在本地弄两个git repo,都从同一个remote repo clone过来,之后自己在里面瞎玩,看看怎么branching/merging啥的不会有问题,哪些事儿做了可能需要resolve conflict。玩一会儿再去自己的production repo里继续干活~

1赞

回答一下问题1:
merge之后master branch上会在head上增加一个单独的merge commit,里面包含了所有你的topic branch从分离以来做出的修改,即都揉成一团扔到一个单独的commit里。如果你之后删除了topic branch,那这个merge commit所对应的内部commit history也就消失了,你只能保留topic branch最终相对于master branch的更改。而rebase会把topic branch从分离以来做出的修改线性合并到master branch上,看起来就像是直接在master branch做出了修改一样,会保留其所有的commit history。所以使用merge还是rebase就要看你想达到的最终效果了。
我自己的使用场景是,如果topic branch是为了实现一个单独的feature,则使用merge,否则其中缝缝补补的commit都会合并回master branch有碍观瞻;而如果topic branch是为了解决一些其他比较少见的问题且commit history相对干净或需要保留,则使用rebase,这种情况比较少见。

我们组当年有个Principle SDE就干过force push直接覆盖了我的代码的事,我只能心里MMP,好在没过多久这位大神主动离职了 :joy:

1赞

回答一下问题6:
一般的实践是在master branch之上建立一个working branch,然后你和同事分别check out from working branch,你们各自完活push之前先merge/rebase working branch,如果有conflict则沟通解决,确认没有conflict之后push到working branch上。最后working branch定期merge回master branch。

主要是,其实并没有发现,因为有个恶性bug需要赶紧覆盖

但是之后azure pipeline被这个forced push搞炸了,全线CI直接崩溃

随意回答一些
3. commit message主要看team的,不同team的要求不一样。有些要求很详细,有些很随意。
5. 这个看个人,你可以一个commit一个push完成一个feature,也可以多次commit多次push,反正最后merge的时候squash一下都差不多。如果你的项目有CI/CD的话多次commit多次push也可以trigger 各种unit/integration/stress tests来帮助debug。我个人的话是每次想跑pipeline了就push一下,然后根据test结果debug。懒得写commit message是出于什么原因?如果是因为要经常切换branch,可以考虑git commit amend 或者 git stash
6. 和楼上某个小伙伴一样,一般而言merge到dev(working) branch出现conflict的话沟通解决,dev branch merge回master则是理论上不会出现conflict. force push是大忌,出现conflict一定要沟通,千万别脑子一热force push

非常感谢~正在认真读廖雪峰的教程 :laughing: 马上就自己本地做实验~

给楼主推荐一下vscode, 每次有conflict,vscode 帮助高亮conflict,上学期帮了大忙, 特别好用 :grinning:

1赞

谢谢你!我刚刚下载了vscode。之前看我们实验室有CS背景的人用vscode,但是我也没问为什么,而且他也不会Git。现在了解了!非常感谢!

1赞

第一份工作在狗家 至今不会复杂的git操作 也不敢说…