├── .nojekyll ├── INTRODUCTION.md ├── 10~Git 仓库 ├── GitLab │ ├── README.md │ └── CI.md └── Github │ ├── 99~参考资料 │ └── 2020-Phodal-《Github 漫游指南》 │ │ ├── 09-maintain-project.md │ │ ├── 19-joke.md │ │ ├── 999-faq.md │ │ ├── 05-create-project-documents.md │ │ ├── 15-milestone.md │ │ ├── 13-read-code.md │ │ ├── 04-commit-message.md │ │ ├── 01-start-project.md │ │ ├── 10-git-tools.md │ │ ├── 16-find-in-github.md │ │ ├── 00-prelude.md │ │ ├── 12-find-github-project.md │ │ ├── 18-get-star.md │ │ ├── 01-introduction.md │ │ ├── 08-github-marketing.md │ │ ├── 07-tdd-with-autotest.md │ │ ├── 02-github-fundamentals.md │ │ ├── README.md │ │ ├── 06-refactor-project.md │ │ ├── 03-build-github-project.md │ │ ├── 14-streak-your-github.md │ │ └── 11-analytics.md │ └── README.md ├── .DS_Store ├── 99~参考资料 ├── mrcode~《Git 系统学习笔记》 │ └── README.md └── GitButler~Git Tips and Tricks │ └── README.md ├── 02~工作流 ├── README.md ├── 功能分支.md └── 99~参考资料 │ └── 2023-林宜丙-Monorepo 下 Git 工作流的最佳实践.md ├── Git 小技巧 └── README.md ├── 09~Git 原理解析 └── README.md ├── 01~基础 ├── 子模块 │ └── 99~参考资料 │ │ └── 2024~Demystifying git submodules.md ├── 分支.md ├── 提交.md ├── Workflow.md ├── README.md ├── 运行机制.md ├── Rebase.md └── 仓库.md ├── .gitignore ├── README.md ├── _sidebar.md ├── index.html ├── header.svg └── LICENSE /.nojekyll: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /INTRODUCTION.md: -------------------------------------------------------------------------------- 1 | # 本篇导读 2 | -------------------------------------------------------------------------------- /10~Git 仓库/GitLab/README.md: -------------------------------------------------------------------------------- 1 | # GitLab 2 | -------------------------------------------------------------------------------- /.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wx-chevalier/Git-Notes/master/.DS_Store -------------------------------------------------------------------------------- /99~参考资料/mrcode~《Git 系统学习笔记》/README.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://zq99299.github.io/note-book/git-scm/) 2 | 3 | # Git 系统学习笔记 4 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/09-maintain-project.md: -------------------------------------------------------------------------------- 1 | 开源项目维护 2 | === 3 | 4 | 5 | Release 6 | --- 7 | -------------------------------------------------------------------------------- /99~参考资料/GitButler~Git Tips and Tricks/README.md: -------------------------------------------------------------------------------- 1 | > [原文地址](https://blog.gitbutler.com/git-tips-and-tricks/) 2 | 3 | # Git Tips and Tricks 4 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/README.md: -------------------------------------------------------------------------------- 1 | # Github 2 | 3 | # 推荐插件 4 | 5 | > [I wanted real time GitHub push notifications. So I built a Chrome extension.](https://parg.co/bD8) 6 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/19-joke.md: -------------------------------------------------------------------------------- 1 | # GitHub 上有趣的故事 2 | 3 | 1. [Remove my password from lists so hackers won't be able to hack me](https://github.com/danielmiessler/SecLists/pull/155) 4 | 5 | -------------------------------------------------------------------------------- /02~工作流/README.md: -------------------------------------------------------------------------------- 1 | # Git 工作流 2 | 3 | ![Git flow](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/item/20230622211550.png) 4 | 5 | # Links 6 | 7 | - https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md 8 | -------------------------------------------------------------------------------- /Git 小技巧/README.md: -------------------------------------------------------------------------------- 1 | # Git 小技巧 2 | 3 | - [Git tips](https://github.com/git-tips/tips): 常用的 Git 小技巧 4 | 5 | - [Git Tips & Tricks](https://wikileaks.org/ciav7p1/cms/page_1179773.html) 6 | 7 | - [2018~Flight rules for git](https://github.com/k88hudson/git-flight-rules): Flight Rules are the hard-earned body of knowledge recorded in manuals that list, step-by-step, what to do if X occurs, and why. Essentially, they are extremely detailed, scenario-specific standard operating procedures. [...] 8 | -------------------------------------------------------------------------------- /09~Git 原理解析/README.md: -------------------------------------------------------------------------------- 1 | # Git Internals 2 | 3 | - [2018~Git 原理入门](http://www.ruanyifeng.com/blog/2018/10/git-internals.html): 这篇文章用一个实例，解释 Git 的运行过程，帮助你理解 Git 的原理。 4 | 5 | - [Git 的核心概念](https://lufficc.com/blog/the-core-conception-of-git): 本文不是 Git 使用教学篇，而是偏向理论方面，旨在更加深刻的理解 Git，这样才能更好的使用它，让工具成为我们得力的助手。 6 | 7 | - [Git 的 Diff 算法分析](http://fabiensanglard.net/git_code_review/diff.php) 8 | 9 | - [探索 .git 目录，让你真正了理解 git](http://blog.jobbole.com/98634/?f=tt) 10 | 11 | - [2017~Git 由浅入深之存储原理](http://blog.codingplayboy.com/2017/03/23/git_internal/)：本来计划本篇介绍 Git 分支的相关知识点与操作，但是准备的过程中发现涉及到很多内部存储原理，决定先介绍一下 Git 存储原理，明白了这些，有助于理解后续内容，对 Git 的使用也会有很大帮助。 12 | 13 | - [2017~Understanding Git Filter-branch and the Git Storage Model](http://6me.us/LDeJQS) 14 | -------------------------------------------------------------------------------- /02~工作流/功能分支.md: -------------------------------------------------------------------------------- 1 | # 功能分支 2 | 3 | ![Pull Request 模型](https://s2.ax1x.com/2019/10/08/ufO1kq.png) 4 | 5 | 推荐团队中采用 Merge Request 的方式进行协作开发，即基于主分支 clone 之后再合并回去： 6 | 7 | ```js 8 | git checkout dev 9 | git pull --rebase --prune 10 | git checkout -b feat/x # or fix/y 11 | 12 | # coding time 13 | 14 | # may commit several times 15 | git commit -m '' 16 | 17 | # make sure rebase from origin dev branch 18 | git fetch 19 | git rebase origin/dev 20 | git push # maybe `-f` flag is required if you've pushed before rebase 21 | 22 | # create Merge Request to dev branch 23 | 24 | # code changes according MR review 25 | 26 | # confirm to rebase again in case others merged before your MR 27 | git fetch 28 | git rebase origin/dev 29 | git push 30 | ``` 31 | -------------------------------------------------------------------------------- /01~基础/子模块/99~参考资料/2024~Demystifying git submodules.md: -------------------------------------------------------------------------------- 1 | ```md 2 | 以下是对 [cyberdemon.org](https://www.cyberdemon.org/2024/03/20/submodules.html) 上 Dmitry Mazin 文章的中文总结： 3 | 4 | 1. **理解子模块**：Git 子模块是一个嵌套在另一个仓库内的仓库。主仓库中的每个提交都会指定它所指向的子模块的具体提交。 5 | 6 | 2. **常见问题**：许多用户发现子模块令人困惑，因为它们被固定在特定的提交上，而且当你在主仓库拉取更改时，Git 不会自动更新它们。 7 | 8 | 3. **更新子模块**：要更新子模块，你可以使用 `git submodule update`。这个命令会将所有子模块更新到主仓库指定的提交。 9 | 10 | 4. **初始化和递归**：在克隆带有子模块的仓库后，你需要使用 `git submodule update --init --recursive` 来初始化和更新它们。这确保所有子模块及其嵌套的子模块都被更新。 11 | 12 | 5. **配置**：你可以通过设置 `git config submodule.recurse true` 来配置 Git 自动更新子模块，但这不适用于克隆操作。 13 | 14 | 6. **添加和修改子模块**：要添加子模块，使用 `git submodule add <仓库地址> <路径>`。如果你修改了子模块，你需要在子模块中提交更改，然后更新主仓库以指向新的提交。 15 | 16 | 这篇文章提供了一个全面的指南，帮助开发者有效地管理子模块，使其用法更加清晰，减少常见的困扰。 17 | ``` 18 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/999-faq.md: -------------------------------------------------------------------------------- 1 | FAQ 2 | === 3 | 4 | ## 如何看待 GitHub 项目刷 Star 行为？ 5 | 6 | 我觉得：在作者开源了源码的情况下，求 Star 并没有任何问题。 7 | 8 | 开源软件的源头是自由软件，而 RMS 创建自由软件的目的是，反对专利软件，即私有化的软件。如果一个开源项目，要你 Star 了，才公开源码，这才叫违反。 9 | 10 | 开源一个软件，并不意味着：你不能用这个开源软件追求任何利益。在所谓的开源运动里，一个开源软件是可以用来卖钱的。可在国内，这是很难的，大公司 如腾讯，可以轻轻松松地用你的软件，而不遵循 GPL 协议。 11 | 12 | 在这种时候，也没有法律来保护这些开源软件作者。你只能从道德上谴责他们，然后指望他们的领导来做出一些什么事。如之前的《[知名公司（努比亚/中兴）拿我的开源软件（ XXL-JOB）申请国家知识专利，我该怎么办？](https://link.zhihu.com/?target=https%3A//www.v2ex.com/t/367424%3Fp%3D1)》事件。 13 | 14 | 并且对于大部分的开源软件作者来说，都不大可能像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。 15 | 16 | 可多数人，并没有这样的可能性。我在 GitHub 上有接近 30k 的 Star（笑，有接近 20k 是属于电子书的，毕竟思想改变世界），它一点儿也不影响我涨工资。反而多了一个 GitHub “网红” 的称号，要知道在技术领域，“网红” 并不是一个好词。我观察过的大量开源爱好者，怕是比我还惨一些。明明做了很好的工作，因为宣传工作没有做好，连几个 Star 都没有，后来就弃坑了。 17 | 18 | 在这个时候，求 Star 就是让心里好受一些，『我做了这么多的事情，我希望得到一些认同』。如果我在一个微信群里，看了作者做了大量的提交，花费了一些心思。在这个时候，我是会去为作者点 Star 的。因为我的 GitHub 上粉丝比较多，所以往往会多带来几个 Star。 19 | 20 | 如果一个人在开源世界里，做了很多事情，连一个 Star 都没有。那么，他/她可能就会离开开源世界。当这种事情发生多了，那么开源世界的人就变少了。任何做开源工作的人，都是值得鼓励的——不论他们是出于什么目的。 21 | -------------------------------------------------------------------------------- /01~基础/分支.md: -------------------------------------------------------------------------------- 1 | # Branch | 分支 2 | 3 | Git 中的分支实际上只是 Commit 指针。 4 | 5 | ```sh 6 | # 命令行中查看版本树 7 | $ git log --pretty=oneline --graph --decorate --all 8 | 9 | # 内置的可视化界面查看版本树 10 | $ gitk --all 11 | 12 | # 根据提交人过滤 Commit 信息 13 | $ git log --author="username" --pretty=format:"%h - %an, %ar : %s" 14 | ``` 15 | 16 | # Manipulation | 操作 17 | 18 | ```sh 19 | # 创建某个分支 20 | git branch BRANCH_NAME 21 | 22 | # 创建并且切换到某个分支 23 | git checkout -b BRANCH_NAME 24 | ``` 25 | 26 | ## Head 27 | 28 | 分支是 29 | 30 | # Merge | 分支合并 31 | 32 | --force 会使用本地分支的提交覆盖远端推送分支的提交。也就是说，如果其他人在相同的分支推送了新的提交，你的这一举动将“删除”他的那些提交！就算在强制推送之前先 fetch 并且 merge 或 rebase 了也是不安全的，因为这些操作到推送之间依然存在时间差，别人的提交可能发生在这个时间差之内。使用此参数推送，如果远端有其他人推送了新的提交，那么推送将被拒绝，这种拒绝和没有加 --force 参数时的拒绝是一样的。 33 | 34 | ## cherry-pick 35 | 36 | git cherry-pick 可以选择某一个分支中的一个或几个 commit(s) 来进行操作，譬如我们存在多个稳定开发版本，在不能完全合并分支的情况下又想把某些功能合入到某个分支，那就可以利用 cherry-pick 对已经存在的 commit 进行再次提交。注意，当执行完 cherry-pick 以后，将会生成一个新的提交；这个新的提交的哈希值和原来的不同，但标识名一样。 37 | 38 | ```sh 39 | # 选择某个其他分支的 commit 合并到当前分支 40 | $ git cherry-pick 41 | 42 | # 如果出现冲突，则类似于 Rebase 进行解决 43 | # 手动查看冲突文件 44 | $ git status 45 | 46 | # 设置文件已经解决冲突 47 | $ git add ... 48 | 49 | # 设置 cherry-pick 继续执行 50 | $ git cherry-pick --continue 51 | $ git cherry-pick --quit 52 | $ git cherry-pick --abort 53 | ``` 54 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore all 2 | * 3 | 4 | # Unignore all with extensions 5 | !*.* 6 | 7 | # Unignore all dirs 8 | !*/ 9 | 10 | .DS_Store 11 | 12 | # Logs 13 | logs 14 | *.log 15 | npm-debug.log* 16 | yarn-debug.log* 17 | yarn-error.log* 18 | 19 | # Runtime data 20 | pids 21 | *.pid 22 | *.seed 23 | *.pid.lock 24 | 25 | # Directory for instrumented libs generated by jscoverage/JSCover 26 | lib-cov 27 | 28 | # Coverage directory used by tools like istanbul 29 | coverage 30 | 31 | # nyc test coverage 32 | .nyc_output 33 | 34 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 35 | .grunt 36 | 37 | # Bower dependency directory (https://bower.io/) 38 | bower_components 39 | 40 | # node-waf configuration 41 | .lock-wscript 42 | 43 | # Compiled binary addons (https://nodejs.org/api/addons.html) 44 | build/Release 45 | 46 | # Dependency directories 47 | node_modules/ 48 | jspm_packages/ 49 | 50 | # TypeScript v1 declaration files 51 | typings/ 52 | 53 | # Optional npm cache directory 54 | .npm 55 | 56 | # Optional eslint cache 57 | .eslintcache 58 | 59 | # Optional REPL history 60 | .node_repl_history 61 | 62 | # Output of 'npm pack' 63 | *.tgz 64 | 65 | # Yarn Integrity file 66 | .yarn-integrity 67 | 68 | # dotenv environment variables file 69 | .env 70 | 71 | # next.js build output 72 | .next 73 | -------------------------------------------------------------------------------- /01~基础/提交.md: -------------------------------------------------------------------------------- 1 | # 提交 2 | 3 | # Commit | 提交 4 | 5 | ```sh 6 | # 管道命令，可用于脚本 7 | $ git diff-tree --no-commit-id --name-only -r bd61ad98 8 | 9 | # 查看某次提交中修改的文件 10 | $ git show --pretty="" --name-only bd61ad98 11 | ``` 12 | 13 | ## 快速提交 14 | 15 | 有时候我们希望能一键执行 add、commit、push 这些操作，可以封装为如下的函数： 16 | 17 | ```sh 18 | function lazygit() { 19 | git add . 20 | git commit -a -m "$1" 21 | git push 22 | } 23 | 24 | # lazygit "My commit msg" 25 | ``` 26 | 27 | 或者封装为单独的 Git alias 命令： 28 | 29 | ```sh 30 | git config --global alias.cmp '!f() { git add -A && git commit -m "$@" && git push; }; f' 31 | 32 | [alias] 33 | cmp = "!f() { git add -A && git commit -m \"$@\" && git push; }; f" 34 | 35 | # 使用方式如下 36 | git cmp "Long commit message goes here" 37 | ``` 38 | 39 | # Tracking | 追踪 40 | 41 | 查看当前追踪的文件信息： 42 | 43 | ```sh 44 | # 展示所有被追踪的文件 45 | git ls-files -t 46 | 47 | # 展示所有未被追踪的分支 48 | git ls-files --others 49 | 50 | # 展示所有被忽略的文件 51 | git ls-files --others -i --exclude-standard 52 | git check-ignore * 53 | git status --ignored 54 | ``` 55 | 56 | ```sh 57 | # 从工作目录中删除文件，同时会暂存信息 58 | $ git rm [file] 59 | 60 | # 从版本控制中移除该文件 61 | $ git rm --cached [file] 62 | 63 | # 本地重命名并且提交 64 | $ git mv [file-original] [file-renamed] 65 | ``` 66 | 67 | # Stash | 贮存 68 | 69 | git stash -- The command saves your local modifications away and reverts the working directory to match the HEAD commit. It allows you to store your uncommited modifications into a buffer area called stash, and deletes it from the branch you are working on. You may later retreive them by applying the stash. 70 | 71 | # Undo | 撤销 72 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/05-create-project-documents.md: -------------------------------------------------------------------------------- 1 | # 创建项目文档 2 | 3 | 我们需要为我们的项目创建一个文档，通常我们可以将核心代码以外的东西都称为文档： 4 | 5 | 1. README 6 | 2. 文档 7 | 3. 示例 8 | 4. 测试 9 | 10 | 通常这个会在项目的最上方会有一个项目的简介，如下图所示： 11 | 12 | ![GitHub Project Introduction](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/github-intro.png) 13 | 14 | ## README 15 | 16 | README 通常会显示在 GitHub 项目的下面，如下图所示： 17 | 18 | ![GitHub README](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/readme-example.png) 19 | 20 | 通常一个好的 README 会让你立马对项目产生兴趣。 21 | 22 | 如下面的内容是 React 项目的简介： 23 | 24 | ![React README](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/react-intro.png) 25 | 26 | 下面的内容写清楚了他们的用途： 27 | 28 | - **Just the UI:** Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. 29 | - **Virtual DOM:** React abstracts away the DOM from you, giving a simpler programming model and better performance. React can also render on the server using Node, and it can power native apps using [React Native](https://facebook.github.io/react-native/). 30 | - **Data flow:** React implements one-way reactive data flow which reduces boilerplate and is easier to reason about than traditional data binding. 31 | 32 | 通常在这个 README 里，还会有： 33 | 34 | - 针对人群 35 | - 安装指南 36 | - 示例 37 | - 运行的平台 38 | - 如何参与贡献 39 | - 协议 40 | 41 | ## 官方首页与在线文档 42 | 43 | 很多开源项目都会有自己的网站，并在上面有一个文档，而有的则会放在[https://readthedocs.org/](https://readthedocs.org/)。 44 | 45 | > Read the Docs 托管文档，让文档可以被全文搜索和更易查找。您可以导入您使用任何常用的版本控制系统管理的文档，包括 Mercurial、Git、Subversion 和 Bazaar。我们支持 webhooks，因此可以在您提交代码时自动构建文档。并且同样也支持版本功能，因此您可以构建来自您代码仓库中某个标签或分支的文档。查看完整的功能列表 。 46 | 47 | 在一个开源项目中，良好和专业的文档是相当重要的，有时他可能会比软件还会重要。因为如果一个开源项目好用的话，多数人可能不会去查看软件的代码。这就意味着，多数时候他在和你的文档打交道。文档一般会有：API 文档、 配置文档、帮助文档、用户手册、教程等等 48 | 49 | 写文档的软件有很多，如 Markdown、Doxygen、Docbook 等等。 50 | 51 | ## 可用示例 52 | 53 | 一个简单上手的示例非常重要，特别是通常我们是在为着某个目的而去使用一个开源项目的是时候，我们希望能马上使用到我们的项目中。 54 | 55 | 你希望看到的是，你打开浏览器，输入下面的代码，然后 **It Works**： 56 | 57 | ``` 58 | var HelloMessage = React.createClass({ 59 | render: function() { 60 | return
Hello {this.props.name}
; 61 | } 62 | }); 63 | 64 | React.render( 65 | , 66 | document.getElementById('container') 67 | ); 68 | ``` 69 | 70 | 而不是需要繁琐的步骤才能进行下一步。 71 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/15-milestone.md: -------------------------------------------------------------------------------- 1 | # GitHub 里程碑 2 | 3 | ## 写在 GitHub 的第 19999 个 Star 时 4 | 5 | > Star 虽好，可不要贪杯哦。 6 | > 两年前在做 Annual Review 订下一年的目标时，想着写一个开源框架。去年订下今年的目标时，仍然继续着这样的想法。今年又要制定下一年的目标，2333~~。 7 | 8 | 不久前，在 GitHub Ranking 上看到自己的 Star 数（Star 不是设计用于做“点赞”的，而是用来收藏的）时，发现已经快 20000 了。然后把自己的项目过了一遍，发现没有一个比较好的**代表性框架**，要么是应用，要么是电子书。 9 | 10 | 前 8 个项目里，除了 Growth 应用以外，其他的都是电子书内容——六本电子书加起来的 Star 数有 **10619**，果然是骗 Star 的。我只能尽力地去想想：为什么事情会变成这样了？ 11 | 12 | ### 从创建开源框架说起 13 | 14 | 创建开源框架和创建开源项目是不一样的，前者你服务于开发者，后者你服务于用户。 15 | 16 | 两年前在做 Annual Review 的时候，想着未来的一年里可以做一个开源框架试试。那时刚毕业不久，对开源世界的各种游戏规则不是很了解：**开源并不是将代码提交上去，然后就会一下子火起来**。虽然我们可以在短期内赚上一些眼球，但是真正要将它采用到项目上的人不多。 17 | 18 | 当时，我遇到的最主要的问题是：**想参与到项目的人并没有遇到足够的能力**。你还需要花费大量的时间去教他们，鼓励 GitHub 新手并不是一件容易的事。有时我需要在接受他的 PR 后，再修改他的代码。并且人们提交 PR 可能是出于不同的原因。 19 | 20 | 然后，知道了开源世界还有一个游戏规则是：**谁的影响力大，谁就能产生更广泛的影响**。如 Virtual Dom 并不是 Facebook 首创的，但是却因为 FB 火的；松本行弘在写下 mruby 的 README 时（印象中是这个项目），Star 数就已经过 1k 了。这种例子数不胜数，要么是在推广上花了力气，要么个人、公司有着更大的影响力。 21 | 22 | 一年前，稍微改变了下策略：暂时以**培养人为主**，同时想着做一个合适的开源框架——只是在今年看来，前端领域已经没有合适的地方可以造轮子了。 23 | 24 | 在 GitHub 上有一个很常见的问题是，**大多数项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。 25 | 26 | 你的开源项目不仅仅需要一个使用文档，还需要一个相关设计思想的文档、路线图、未来计划等等。 27 | 28 | 去年年底写总结的时候，想到可以 RePractise 文章为基础来培养人，于是就有了 Growth 的三个项目： 29 | 30 | - 应用：[Growth](https://github.com/phodal/growth) 31 | - 电子书：《[Growth：全栈增长工程师指南](https://github.com/phodal/growth-ebook)》 32 | - 电子书：《[Growth：全栈增长工程师实战](https://github.com/phodal/growth-in-action)》 33 | 34 | 如今 Growth 已经有了过万的用户，每天活跃的用户数也接近 300 了。第一步看上去很成功，但是下一步怎么走呢？ 35 | 36 | ### 下一个开源项目 37 | 38 | 后来我开始在思索一个问题，创建一个开源框架是必须的吗？ 39 | 40 | 在编写 Growth 电子书的时候，我发现一个好的软件工程实践远远比一个易上手的框架重要多了。框架本身是易变的东西，过去你在用 Backbone，现在你在用 React.js；过去你在用 Angular.js，现在你在用 Vue。会不会使用某个框架，并不是区分你是不是一个有经验的开发者的标准。 41 | 42 | 一直将焦点关注于**学习不同的框架的使用**是有问题的，一个在校生可以轻松地比你了解某个框架的原理——你白天在工作，而他整天在学习。这时你很容易就失去竞争力了，你需要从框架之外了解更深层次的东西。**一个好的框架并不能让你写出一段好的代码**。 43 | 44 | > 如果中国人的思想不觉悟，即使治好了他们的病，也只是做毫无意义。 45 | 46 | 这算是我为自己在 GitHub 下的 Markdown 的自辩吧——谁让我一直有写作的冲动呢。 47 | 48 | 不过我仍然还有一些想法，只是还没有抽出足够的时间去思考这样的事。 49 | 50 | **GNU/Linux 的桌面**。这是几年前的一个想法了，当时 GNU/Linux 的那些操作系统上都没有一个好玩的桌面，不过感觉这个坑太深了，就没有进行了。 51 | 52 | **家居智能中心**。我仍然对于大学学的知识有点念念不忘，虽然已经写了一本书，但是硬件还是相当的刺激。唯一的问题是：连房子都没有，怎么做智能家居。 53 | 54 | **图形框架**。这是我之前在做一个图形界面的时候，发现没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。 55 | 56 | 不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工具来给自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。 57 | 58 | 最后，我做了一个简单的 HTML 5 动画来记录这一时刻，作为这一个里程碑的记念： 59 | 60 | [https://phodal.github.io/20k/](https://phodal.github.io/20k/) 61 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/13-read-code.md: -------------------------------------------------------------------------------- 1 | # 如何以“正确的姿势”阅读开源软件代码 2 | 3 | > 所有让你直接看最新源码的文章都是在扯淡，你应该从“某个版本”开始阅读代码。 4 | 5 | 我们并不建议所有的读者都直接看最新的代码，正确的姿势应该是： 6 | 7 | - clone 某个项目的代码到本地 8 | - 查看这个项目的 release 列表 9 | - 找到一个看得懂的 release 版本，如 1.0 或者更早的版本 10 | - 读懂上一个版本的代码 11 | - 向后阅读大版本的源码 12 | - 读最新的源码 13 | 14 | 最好的在这个过程中，**可以自己造轮子来实现一遍**。 15 | 16 | ## 阅读过程 17 | 18 | 在我阅读的前端库、Python 后台库的过程中，我们都是以造轮子为目的展开的。所以在最开始的时候，我需要一个可以工作，并且拥有我想要的功能的版本。 19 | 20 | ![it-works-cms.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/it-works-cms.png) 21 | 22 | 紧接着，我就可以开始去实践这个版本中的一些功能，并理解他们是怎么工作的。再用 `git` 大法展开之前修改的内容，可以使用 IDE 自带的 Diff 工具： 23 | 24 | ![pycharm-diff.jpg](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/pycharm-diff.jpg) 25 | 26 | 或者类似于 `SourceTree` 这样的工具，来查看修改的内容。 27 | 28 | 在我们理解了基本的核心功能后，我们就可以向后查看大、中版本的更新内容了。 29 | 30 | 开始之前，我们希望大家对版本号管理有一些基本的认识。 31 | 32 | ## 版本号管理 33 | 34 | 我最早阅读的开始软件是 Linux，而下面则是 Linux 的 Release 过程： 35 | 36 | ![linux-history.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/linux-history.png) 37 | 38 | 表格源自一本书叫《Linux 内核 0.11(0.95)完全注释》，简单地再介绍一下： 39 | 40 | - 版本 0.00 是一个 hello, world 程序 41 | - 版本 0.01 包含了可以工作的代码 42 | - 版本 0.11 是基本可以正常的版本 43 | 44 | 这里就要扯到《GNU 风格的版本号管理策略》： 45 | 46 | 1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式； 47 | 2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1； 48 | 3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉； 49 | 4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1； 50 | 5. 另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。 51 | 52 | 因此，我们可以得到几个简单的结论： 53 | 54 | - 我们需要阅读最早的有核心代码的版本 55 | - 我们需要阅读 1.0 版本的 Release 56 | - 往后每一次大的 Release 我们都需要了解一下 57 | 58 | ## 示例 59 | 60 | 以 Flask 为例： 61 | 62 | 一、先 Clone 它。 63 | 64 | ![clone-flask.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/clone-flask.png) 65 | 66 | 二、从 Release 页面找到它的早期版本： 67 | 68 | ![flask.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/flask.png) 69 | 70 | 三、 从上面拿到它的提交号 `8605cc3`，然后 checkout 到这次提交，查看功能。在这个版本里，一共有六百多行代码 71 | 72 | ![flask-0.1.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/flask-0.1.png) 73 | 74 | 还是有点长 75 | 76 | 四、我们可以找到它的最早版本： 77 | 78 | ![flask-init.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/flask-init.png) 79 | 80 | 然后查看它的 `flask.py` 文件，只有简单的三百多行，并且还包含一系列注释： 81 | 82 | ![flask-init.png](https://ngte-superbed.oss-cn-beijing.aliyuncs.com/book/phodal-github/flask-init.png) 83 | 84 | 五、接着，再回过头去阅读 85 | 86 | - 0.1 版本 87 | - 。。。 88 | - 最新的 0.10.1 版本 89 | -------------------------------------------------------------------------------- /10~Git 仓库/Github/99~参考资料/2020-Phodal-《Github 漫游指南》/04-commit-message.md: -------------------------------------------------------------------------------- 1 | Git 提交信息及几种不同的规范 2 | === 3 | 4 | > 受 Growth 3.0 开发的影响，最近更新文章的频率会有所降低。今天，让我们来谈谈一个好的 Git、SVN 提交信息是怎样规范出来的。 5 | 6 | 在团队协作中，使用版本管理工具 Git、SVN 几乎都是这个行业的标准。当我们提交代码的时候，需要编写提交信息（commit message）。 7 | 8 | 而提交信息的主要用途是：**告诉这个项目的人，这次代码提交里做了些什么**。如，我更新了 React Native Elements 的版本，那么它就可以是：``[T] upgrade react native elements``。对应的我修改的代码就是：``package.json`` 和 ``yarn.lock`` 中的文件。一般来说，建议**小步提交**，即按自己的 Tasking 步骤来的提交，每一小步都有对应的提交信息。这样做的主要目的是：**防止一次修改中，修改过多的文件，导致后期修改、维护、撤销等等困难**。 9 | 10 | 而对于不同的团队来说，都会遵循一定的规范，本文主要会介绍以下几种写法： 11 | 12 | - 工作写法 13 | - 常规写法 14 | - 开源库写法 15 | 16 | 那么，先从我习惯的做法说起。 17 | 18 | 工作写法 19 | --- 20 | 21 | 在我的第一个项目里，我们使用 Jira 作为看板工具，Bamboo 作为持续集成服务器，并采用结对编程的方式进行。 22 | 23 | 在 Jira 里每一个功能卡都有对应的卡号，而 Bamboo 支持使用 Jira 的任务卡号关联的功能。即在持续构建服务器上示例对应的任务卡号，即相应的提交人。 24 | 25 | 因此，这个时候我们的规范稍微有一些特别： 26 | 27 | ``` 28 | [任务卡号] xx & xx: do something 29 | ``` 30 | 31 | 比如：``[PHODAL-0001] ladohp & phodal: update documents``，解释如下： 32 | 33 | - ``PHODAL-0001``，业务的任务卡号，它可以帮我们找到某个业务修改的原因，即点出相应 bug 的来源 34 | - ``ladohp & phodal`` ，结对编程的两个人的名字，后者（phodal）一般是写代码的人，出于礼貌就放在后面了。由于 Git 的提交人只显示一个，所以写上两个的名字。当提交的人不在时，就可以问另外一个人修改的原因。 35 | - ``update documents``，我们做了什么事情 36 | 37 | 缺点：而对于采用看板的团队来说，并不存在任务卡号这种东西，因此就需要一种额外的作法。 38 | 39 | 常规写法 40 | --- 41 | 42 | 对于我来说，我则习惯这种的写法： 43 | 44 | ``` 45 | [任务分类] 主要修改组件（可选）：修改内容 46 | ``` 47 | 48 | 示例 1，``[T] tabs: add icons`` 。其中的 ``T`` 表示这是一个技术卡，``tabs`` 表示修改的是 Tabs，``add icons`` 则表示添加了图标。 49 | 50 | 示例 2，``[SkillTree] detail: add link data``。其中的 ``SkillTree`` 表示修改的是技能树 Tab 下的内容，``detail`` 则表示修改的是详情页，``add link data`` 则表示是添加了技能的数据 51 | 52 | 这样做的主要原因是，它可以轻松也帮我 **filter 出相应业务的内容**。 53 | 54 | 缺点：要这样做需要团队达到一致，因此付出一些额外的成本。 55 | 56 | 开源应用、开源库写法 57 | --- 58 | 59 | 与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANGELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。 60 | 61 | 因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式： 62 | 63 | ``` 64 | (): 65 | 66 | 67 | 68 |