GitHub应该放什么类型的代码?

Question

因为我现在编码的水平还属于初阶,所以在写一些oj(online judge)上的一些小程序做练习.
请问这类代码适合放上GitHub吗?

打算放到GitHub的目的是觉得可以方便些(GitHub具体的功能还不是很了解)

如果未来我需要找工作时给出我的GitHub,这些小程序会降低在考官眼里的形象吗?

Answer 1

Github ≠ 有 Github 帐号

我想，现在很多程序员都对 Github 存在误解。

大多都是觉得『虽不明，但觉厉』的样子，以为有个 Github 帐号就算是世界级的程序员了。

由于公司招聘有 Github 加分，所以很多人都把 Git 地址贴过去，然后就这样：

其中不乏工作 5 年以上的，煞有介事的把 空无一物 的 Github 地址粘贴过去。
个人来说，我要看应聘者的 Github，就是看你

• 做了什么项目
• 编码风格如何
• 能不能用 Git 做好版本控制
• commit message 写得怎么样
• 工程管理习惯
• 等等

从一个小地方能看出很多东西，我想如果 10 来分钟就能大致了解一个人的水平如何，不是能很好的节省招聘成本，为双方省时间么？

Markdown

现在有很多工作 5 年以上的程序员，Markdown 都不会好好写（我不仇视也不鄙视这样的人，因为都是可以学的）。Github 一个仓库下来总要写个 README.md 的吧？README.md 也能告诉我很多信息：

• Markdown 水平不说
• 文档的编写风格决定了我能不能跟 TA 做朋友（无所谓的态度、乱糟糟的文档，我不喜欢这样的程序员，哪怕他水平比我高很多，团队协作的时候他会不在乎很多东西）
• 把合作对象当做用户来友好对待（一个好的 README.md 能让别人省很多事情，同样，一个清晰明了的文档能让 coworker 少很多愚蠢的问题）

你真的会用 Git?

很久之前，我还是个无知的菜鸟的时候（当然我现在也很弱，但我知道自己是无知的），我恐惧 CLI（命令行），依赖 GUI（图形工具，IDE 自带），然后勾选修改 -> commit -> pull -> merge -> checkout，大概就这么多了，这都没有问题的，好歹能用上版本控制了不是？

但是我想用 GUI 的人，多多少少没有良好的 Git 使用习惯，conflict 处理粗暴简单，不管提交能不能 Fast forward，提交就是了，merge develop from xxxx.com into develop这种粗暴的 merge？没关系，TA 不在意。

Git 的学习曲线确实相对陡峭，除了基础的哲学理念让人糊涂，Git 很多陷阱难以轻易的复现，学习起来非常痛苦，它简洁，却又晦涩难懂。你用 git add | git commit | git push | git pull | git merge 觉得已经够了，等到你做了一些让队友恨得牙痒痒的事情的时候，你发现那几条单薄的命令只会让你难堪。

rebase 是什么东西？好吃吗？

没有学会用 rebase，就别出去跟人说会用 Git 了。Git merge 合并让你觉得成就感爆棚，但是看看别人是如何优雅的使用 rebase 衍合分支的，心里总归有点儿羡慕吧。

不小心 reset --hard 了，代码全没了！

与其哭着重新写一遍，不如了解下 Git DVCS 是用来干嘛的。
git reflog 找到自己的提交记录，git cherry-pick [commit hash code]，喏，代码还在呢。

merge 之外，另有一番天地

git rebase --onto
git rebase -i
等到基础差不多了，玩玩这两条命令吧。

好好写 commit message!

相信这样的 commit message 不少见：

• init
• update
• merge
• chore
• 提交
• 解决了一些问题
• 增加了一些功能

我去，大神你写这样的 commit message 给鬼看啊？git log 你看看都是写的是些什么，我真不指望你看着 commit 时间戳就能知道那天你干了什么。

看看别人怎么写的吧：

• feat(超文本驱动和资源发现): 增加了 JSON API 方案
• fix(请求方法): 更新完资源后应该返回状态码 202
• chore(): 增加了补充性质的文件 SUPPLEMENT.md

诶，是不看起来是 readable 了？

分享与协作 —— Github 之真义

Git 不是看两本书就能立地成牛了，是要在日常版本管理与协作中锻炼出来的。

没事给自己经常用的第三方库提几个 issue，改几个 bug 写几行代码，然后提起 pull request。

同样的，自己有个好的 idea 也可以写个框架提交在上去，广邀四方英雄来参与你的项目。

这里其实有很多要说的，却发现什么也说不出来了。

哦，忘记重点了，不要怕初级太简单而被人鄙视，谁都是这么过来的。

另外也别光说不练，贴上我的 Github，其实还有很多改善的地方。如前面所说：我知道自己无知，我在努力。;-)

Answer 2

oj一类单文件的代码，或者是给他人分享代码片段，适合放在github gist。

github适合放置公开运营，有开源许可证，适合他人重用的项目，这个项目的规模倒是可大可小，小到一个实用类也很平常，但是建议封装良好、便于使用。

可以准备github小号放置不完善的草稿，以及大号没玩好废弃掉的项目。

Answer 3

整个 /hell-world.git (typo... but not bad :P)
我觉得挺好的。

Answer 4

鄙視基礎的人纔會被考官鄙視。

Answer 5

不会的 放心的去写吧

Answer 6

我就把leetcode和欧拉计划的答案放在github上了啊 怕啥

Answer 7

可以的，你的 github 你做主。

Answer 8

不要放经常易变话数据 ， 比如你把它当云存储了 （岛国X ， 什么你训练模型数据 （每天一更新）！）
我感觉git ，是一个平台 ， 你可以学习很多大牛代码风格 ， 他们编程角度 ， 你可以先star ， 如果对某个项目感觉很可以 ， fork（本人没干过 ， 能力有限） ， 还有 编程有个大牛说过 ， 大牛 ， 就是 每天都写一点代码 ， 我感觉很多人应该在git上逛一逛 ， 很多人写代码真的很糟糕 ， 但是环境很密闭 ， 感觉自己真的很nb ，为了有个好点的工作 ， 你可以写写自己代码 ， 注意多看 ， 希望有天我们也可以成为大牛 ！ 感谢github