因为我现在编码的水平还属于初阶,所以在写一些oj(online judge)上的一些小程序做练习.
请问这类代码适合放上GitHub吗?
打算放到GitHub的目的是觉得可以方便些(GitHub具体的功能还不是很了解)
如果未来我需要找工作时给出我的GitHub,这些小程序会降低在考官眼里的形象吗?
因为我现在编码的水平还属于初阶,所以在写一些oj(online judge)上的一些小程序做练习.
请问这类代码适合放上GitHub吗?
打算放到GitHub的目的是觉得可以方便些(GitHub具体的功能还不是很了解)
如果未来我需要找工作时给出我的GitHub,这些小程序会降低在考官眼里的形象吗?
oj一类单文件的代码,或者是给他人分享代码片段,适合放在github gist。
github适合放置公开运营,有开源许可证,适合他人重用的项目,这个项目的规模倒是可大可小,小到一个实用类也很平常,但是建议封装良好、便于使用。
可以准备github小号放置不完善的草稿,以及大号没玩好废弃掉的项目。
不要放经常易变话数据 , 比如你把它当云存储了 (岛国X , 什么你训练模型数据 (每天一更新)!)
我感觉git ,是一个平台 , 你可以学习很多大牛代码风格 , 他们编程角度 , 你可以先star , 如果对某个项目感觉很可以 , fork(本人没干过 , 能力有限) , 还有 编程有个大牛说过 , 大牛 , 就是 每天都写一点代码 , 我感觉很多人应该在git上逛一逛 , 很多人写代码真的很糟糕 , 但是环境很密闭 , 感觉自己真的很nb ,为了有个好点的工作 , 你可以写写自己代码 , 注意多看 , 希望有天我们也可以成为大牛 ! 感谢github
Github ≠ 有 Github 帐号
我想,现在很多程序员都对 Github 存在误解。
大多都是觉得『虽不明,但觉厉』的样子,以为有个 Github 帐号就算是世界级的程序员了。
由于公司招聘有 Github 加分,所以很多人都把 Git 地址贴过去,然后就这样:
其中不乏工作 5 年以上的,煞有介事的把 空无一物 的 Github 地址粘贴过去。
个人来说,我要看应聘者的 Github,就是看你
从一个小地方能看出很多东西,我想如果 10 来分钟就能大致了解一个人的水平如何,不是能很好的节省招聘成本,为双方省时间么?
Markdown
现在有很多工作 5 年以上的程序员,
Markdown
都不会好好写(我不仇视也不鄙视这样的人,因为都是可以学的)。Github 一个仓库下来总要写个README.md
的吧?README.md
也能告诉我很多信息:Markdown
水平不说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 不少见:
我去,大神你写这样的 commit message 给鬼看啊?
git log
你看看都是写的是些什么,我真不指望你看着 commit 时间戳就能知道那天你干了什么。看看别人怎么写的吧:
feat(超文本驱动和资源发现): 增加了 JSON API 方案
fix(请求方法): 更新完资源后应该返回状态码 202
chore(): 增加了补充性质的文件 SUPPLEMENT.md
诶,是不看起来是
readable
了?分享与协作 —— Github 之真义
Git 不是看两本书就能立地成牛了,是要在日常版本管理与协作中锻炼出来的。
没事给自己经常用的第三方库提几个
issue
,改几个 bug 写几行代码,然后提起pull request
。同样的,自己有个好的 idea 也可以写个框架提交在上去,广邀四方英雄来参与你的项目。
这里其实有很多要说的,却发现什么也说不出来了。
哦,忘记重点了,不要怕初级太简单而被人鄙视,谁都是这么过来的。
另外也别光说不练,贴上我的 Github,其实还有很多改善的地方。如前面所说:我知道自己无知,我在努力。;-)