tianyilt / ecust-courseshare Goto Github PK

闲来无事一个sync+pull,发现了好多压缩包

有没有将压缩包拆开成目录的必要？

感谢前辈分享华理数据结构PPT，本人考研党，准备了2020的考研，全网搜索没有找到ECUST的专业课资料，万幸在Git上找到您以及分享之资料。本人打算报考贵校的计算机技术专业，希望能认识师兄并给予我经验，斯人在这留下Wechat ID：qiaoz426，希望前辈能与我联系，感激不尽！

计划结构如下

文件结构：

• 文档.assert[用于存放文档所需图片]

  • 图片名.png

• 文档.md[基于markdwon编写的文档]

• 公共选修

  • 公共选修课程

• 公共必修

  • 公共必修课程

• 专业课程

  • 专业必修
    • 专业必修课程
  • 专业选修
    • 专业选修课程

课程文件夹设置

• 课程文件夹
  • README.md[用来存放课程总体攻略心得,如果课程内容过于庞大,建议单独开个仓库,然后在readme内加上链接]
  • README.assert[用于存放README.md所需图片]
    • 图片.png
  • 考试
    • 年份-期中/期末-试卷.png
    • 年份-期中/期末-试卷.pdf[如果图片太多需要合并为pdf]
  • 作业
    • 作业参考书.pdf
    • 作业难题解析.md/doc[平时一些题目的解析]
  • 课件与教材
    • 教材名[部分教材过大,因此需要切分,因此放入文件夹]
      • 教材1.pdf
      • 教材2.pdf
    • 课件
      • 课件1.pdf/ppt
      • 课件2.pdf/ppt
  • 复习
    • 思维导图
      • 年份-期中/期末.mmap/xmind
    • 复习文档
      • 年份-期中/期末.doc
      • 开卷纸

I have found this problem for such a long time and I always forgot to raise it as an issue to fix

https://lpd-ios.github.io/2017/05/03/GitHub-Badge-Introduction/

最近由于提交的资源量快速增长，仓库的大小已经超过了10GB。

对于普通的贡献者来说，--depth=1是一个很好的解决方法，但作为20级的贡献者之一的我和Liz已经感到其中内容的混乱性

其中尤其令人头大的

1. 需要专有软件才能打开的xmind思维导图
2. 部分课程的电子书或参考教材以pdf或者是zip/rar形式
3. 甚至有人还上传了软件的安装包（-_-
4. 文件夹内部的命名混乱，不直观

是时候开始做一些改变了。
对于需要分享的大文件存储，我倾向于用超星的资源库，或者是我校的上传接口上传内容，可以利用超星的永久直链功能大幅度加速下载

TieBaMma/InstallTutorial#33 (comment)

这里面有详细的介绍。虽然我现在都是 Telegram 存文件了XD，单文件 2G，无限容量。

https://www.6ccloud.com/

百度/Google 搜 计 131 就能找到了。

包括首页readme里的和教程里面返回readme的链接

我的邮箱一直收到这个邮件

The page build completed successfully, but returned the following warning for the master branch:

It looks like you're using GitHub Pages to distribute binary files. We strongly suggest that you use releases to ship projects on GitHub. Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software. We found the following file(s) which may be a good candidate for releases: 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter13/WindowsFormsApplication1/WindowsFormsApplication1/bin/Debug/WindowsFormsApplication1.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter13/WindowsFormsApplication1/WindowsFormsApplication1/bin/Debug/WindowsFormsApplication1.vshost.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter13/WindowsFormsApplication1/WindowsFormsApplication1/obj/x86/Debug/WindowsFormsApplication1.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter4/c++/P.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter4/c++/P2.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter4/c++/P3.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter4/c++/test4.exe, 信息科学与工程学院/Java程序设计实验/课件和源代码/课件和源代码/java_source/chapter4/c++/testsize.exe, 数学系/专业选修/大3上_计算机网络/实验报告/实验五/Win32OpenSSL-1_0_2t.exe, and 数学系/专业选修/大3下_投资学/作业/金太阳行情交易软件/new_gxzq_v6.62.exe.

虽然README里提到了license，但最好还是放一个LICENSE文件

即将获得服务器授权, 接下来计划在linux系统下配置gitlab来承载本项目

可能出现的问题和解决方案

• 目前不清楚徐汇校区网段和奉贤校区网段是否一致,已经会有外网访问问题,计划使用frp协议,用阿里云服务器进行中转.
• 维护所需要的技术水平越来越高了, 20-18级还没找到接班人

我校有比较多的学院共享同一门课程，同时同一门课程又有不同学分，可能会对找寻自己的课程造成一些困扰。是否可以通过开课学院，进行重新分类？比如有机、物化等归入化学系，化工原理与化工原理（少学时）等归入化工系这样，公选课也可以按照开课学院来分

比较重要的问题

• 仓库大小:
  • 这是一个相当不理智的数值. 尽管理论上Github规定的仓库大小最大不能超过100GB, 但强烈建议单个仓库大小不要超过1GB, 这会给各部分的流程带来压力.
  • 事实上, 我在文件目录中看到了一些视频文件, 它们对于问题的阐释可能是必要的, 但一个更好的方法是将它们上传到视频网站上, 留下一个链接即可.
    • 同样的, 文件目录中有大量未经压缩的图片文件, 或许可以考虑 @ImgBotApp ?
    • 或者先压缩, 然后打包上传, 这也能一定程度上的缓解问题.
  • 当然, 最重要的是应当合理筛选需要上传的文件, 以确保合适的仓库大小.
    • 至少请记得在上传文件时删除某些系统文件以及图片中的附加信息, 这也是处于个人信息安全的考量.
• 版权问题
  • 我在文件目录中看到了相当多的教材(包括但不限于教材主体, 其附属的参考答案, 学习资料等), 这也是仓库大小膨胀的原因之一. 更重要的是, 可能会带来版权问题.
    • 某些教材(尤指一些外文教材或其译本), 是受到版权保护的, 其数字版本被禁止公开传递.
      • 这并不能通过README中最后一句: 其他部分的版权归属于其各自的作者 来回避.
      • 这可能导致本项目被Takedown
        • 当然由于各种各样的原因, 这并不常见, 但出于各种各样的考虑(笑), 建议尽量回避.
  • 或许单独设立一个教材归档的仓库会更为合适. 当然, 我更倾向于这是一个教材推荐的Repo或讨论页.

一些关于用户体验优化的建议

• 项目结构
  • 基于目前项目结构比较混乱, 随便扯一点自己的思路.
  • 主分类
    • 该想法基于以下考量:
      • 大多数情况下, 一个用户的操作范围仅限于公共课程和其所属专业课程. 默认情况下不需要与其他专业课程交互, 下载本项目归档文件或Clone时包含所有内容是不合理的.
      • Github基于分支生成相应的归档文件
        • 如本项目master分支的归档文件: 📁ecust-CourseShare-master.zip
      • Git也可以Clone单个分支
        • $ git clone --branch <name> <repository>
    • 综上, 提出主分类方案:
      • master分支调整为本项目的docs.
        • 当然亦可另开一个docs分支, 保留master为完整合并, 提供给有意图全科目制霸的大佬(笑).
      • 使用branch代替一级文件夹进行分类.
        • 每个分支代表一个专业(或公共分类).
        • 优点
          • 用户只需要下载或Clone对应的分支即可, 而不是整个项目仓库.
        • 缺点
          • 这是branch的错误使用方法(笑).
          • 略微增加了一点学习成本: 如何切换分支(笑).
  • 目录结构
    • 课程名称\年份\分类\
      • 课程名称: 应当使用完整准确的课程名, 建议在名称开头添加首字母, 便于索引.
      • ..\年份: 考虑到时效性, 将其作为一个优先级较高的分类, 也有利于日后可能需要的过时资源归档.
      • ..\分类: 按照资源类型进行分类, 应当有一套完整, 全面, 统一的分类方案.
        • 还没有想好具体的实现, 或许可以开一个Issue详细讨论一下?
      • ..\: 底层目录
        • 除底层目录外, 任何父目录不应包含任何除README以外的文件
        • 文件命名规则: 课程名称-年份-分类-文件名
          • 便于在整个项目仓库中查找特定文件
• Github Pages
  • 关于本项目的Github Pages, 一般有两个用法:
    • VISAUL: 本质上是单纯的视觉效果, 提供一个感觉上更为友好的界面.
      • 但不得不说Github本身已经较为友好, 而且套一层Github Pages降低加载速度...(笑)
        • 虽然正好可以拿来试试Github Actions(笑).
      • 可以考虑使用MkDocs等docs框架.
    • UTIL: 功能性的设计, 提供更多的功能.
      • 例如月度总结, 优秀资源PICK UP, 优秀攻略推送之类的.
        • 这一建议出于以下考量:
          • 跟踪项目的更新情况较为困难, 尤其是目前Commit Message过于含蓄的情况下.
            • 下面还会详细讨论关于Commit Message的问题.
          • 突出展示优秀资源, 便于学习, 进而提升整体质量.
      • 当然这就需要有人来写Blog(笑).
      • 可以考虑使用hexo等blog框架.

一些和用户体验无关但和维护体验息息相关的建议

• Commit规范
  • 虽然这并不是一个一周一回滚一月一重构的项目(笑), 但保持清晰的Commit记录还是有必要的. 适当合并或拆分Commit, 确保每次做完且只做了一件事, 再配上详细完整的Commit Message, 能使记录看起来清爽许多, 也更便于维护.
    • 顺便一提, 规范的Commit Message几乎就可以当作是Change Log, 配合Project Boards可以快速定位需要补全\修正的资源.
  • 可以考虑使用一道专用的Commit Template.
• 其他
  • 写一个Pull Request Template.
  • 使用一些更好的方式维护Contributors.
    • 比如 @all-contributors ?
  • 关闭暂未使用的功能.
  • TODO | ...

我将项目提交给组织之后,lfs失效,容量上限只有1G,因为我们项目太大,要购买额外存储

在赶 ddl 时摸鱼写的 issue

在偶然和 @tianyilt 交流前，我甚至不知道这个站点。就更不用提那些连 GitHub 都不知道的同学了。因为认知规律应该是 认识 GitHub -> 发现这个站

我也算是提交了不少资料，发现了一些问题。现在列在下面。

1. 资料基本是有时效性的，加上原本资料的封闭性，所以理想情况是单独年级的某专业的同学来上传某专业资料。但是 \摊手。这种用爱发电持续不了多久的。

2. 在 wx 朋友圈里发现很多同学转载的某公众号的推广链接，用推广换资料。想到这篇文章。中文互联网的产出在渐渐枯萎吗？ - 陶韵的回答 - 知乎 ，并不是说不好，而是感慨大势已去。

3. 和一个别的学校的 QQ 好友聊了一下，他也打算给他们的学校整一个。说明这件事本身算是可以的。

4. 暂无

一些想法：

1. 可以让老师直接把资料传上来。因为老师是信息来源。

2. 学生会帮忙推广啥的。

3. 让 CS 的同学学习 GitHub 的基本用法（笑

目前仓库大小接近6G多，就算学废了廖雪峰的git教程也没办法直接对本仓库产生贡献。需要开个坑讲解一下最简单的贡献文件的方式，并进行小范围试点。

要讨论的议题包括

• 快速了解项目结构，比如可以通过github1s.com/tianyilt/ecust-CourseShare来查看整个项目的目录结构。并配合doc来初步了解。

• 一步步的fork，找到目录上传，然后重新pull request回来的方法，特别是如果目录传错了怎么补救。

• 如果希望可以把项目拉到本地，进行细节化操作，我们的攻略可能包括

  1. 通过一些比较快的镜像源 clone 项目
  2. 修改项目的上游分支为自己fork好的仓库
  3. gui或者命令行上add commit push pull 解决冲突

• 除了fastgit这样的地址，还有一个像百度网盘那样方便浏览的地方来进行其他操作的攻略

这些文本和多媒体材料我有部分了，得看看放在readme什么地方比较好。