Gitは最初1244行しかなかった
概要 Junio C Hamanoさんに興味を持って調べていると、Linusさんが書いたGitの初版は1244行ということが分かりました。Gitの初版について、軽く行数の確認とビルドチャレンジをして、あまり調べずに動かしながら機能を推測してみました。 はじめに Highlights from Git 2.39 の冒頭で登場するcommit数が一番多い方「Junio C Hamano」さんを知らなかったので調べてみました。 gihyoのインタビュー記事が面白かったです。Junio C HamanoさんはGitのメンテナで、LinusさんからGitのメンテナを引き継いだすごい方だということを知りました。 このgihyoのインタビュー記事の中で「MLで流れてきたGitのコード行数は1244行だった」というところが気になりました。調べてみると、2020年にTwitterでRui Ueyamaさんへ
Gitのコミットメールアドレスに他人のメールアドレスを使用してはいけない | Qrunch（クランチ）
Gitではコミットする際に任意のメールアドレスを指定することができます。任意に設定する値なので存在しないアドレスや、他人のメールアドレスでも登録できますが、Githubでソースコードを公開している場合は注意が必要です。 Githubではコミット時のメールアドレスをもとにコミット履歴に表示するユーザーアカウントを特定しているため、もしもコミット時に指定したメールアドレスが他人のGithubアカウントのメールアドレスとして登録されていた場合、そのコミットは他人のGithubアカウントに紐づけられてしまいます。 例えば、あるOSSプロジェクトで誰かが [email protected] という適当なメールアドレスを使用してコミットを実施したとします。 commit 603a85fcdabb66c337c1740d4db85208bf50e05f (HEAD -> master, origin/m
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
GitHub おじさん スターターキット - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する
「Wikipediaをwikiって略すな」に敗北した我々の負けられない戦い「GitHubをGitって略すな」 - YAMDAS現更新履歴
期間限定公式サイト「村上さんのところ」で、村上春樹が Wikipedia を wiki と略しているっぽい記述を以前見かけた。 僕もすぐにものを忘れてしまいます。最近はwikiがあるのでなにかと助かりますが。 村上さんのところ／村上春樹 期間限定公式サイト これだけ読んで彼に「Wikipediaをwikiって略すな」と噛み付いてはいけないのだが（本当にミュージシャンの情報を集積した Wiki サイトを指しているかもしれないし）、これを読んで、もはや村上春樹までそうするなら、「Wikipediaをwikiって略すな」というのはもう諦めなければならないのではないかと思ったりした。 そういえば日清焼そばU.F.O.における保健室の美月先生のプロフィールページにも、「趣味：ネットサーフィン（主にwiki）」とあったな。関係ないけど、このシリーズの山本美月はそれほど魅力的に見えない。 しかし、それよ
gitblit 入門 - udagawa’s blog
gitblit とは gitblit はオープンソースな git server。今は ticket も管理できるようになっている。 http://gitblit.com/ 1.4.0 から ticketが追加。 1.5.0 から java7で動くようになった。 1.6.1 現在(そろそろ1.7.0がでそうだ) gitblit を使うきっかけ 最初 gitlab(https://about.gitlab.com/) をつかっていたが遅い(gitのプロセス起動してパースしているので。https://gist.github.com/catatsuy/8827731 が詳しい)ので gitblit に乗り換えた。 gitblit はプラグインが groovy でかけるので気に入っている。 gitblit 自体は Java で Wicket をつかって書かれている。git 操作は JGit、検索には
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
研究室でGithub勉強会をしました。 - FromAtoMemo
@10月18日 世はまさに、大ソーシャル時代！ というわけで、研究室でGithub勉強会をしました。 ある日私は、研究室の課題で『もじたま』を作っていました。この課題はグループワークだったのですが、"1台のパソコンにグループメンバーが集まってコーディングやデバッグをする"という、つらぽよ案件が多発していて、「このまま放置しておいたら、人が死ぬぞ……。」と思ったのが、勉強会をしようと思ったきっかけです。 ローカルな不幸を減らす為に 恐らく、学生がよく聞く（言う）セリフとして 「研究室にソースコード忘れて、家でデバッグできない。」 「最新データ入れたUSBメモリ忘れた。」 「パソコンクラッシュして、全データ死んだ。」 があります。これをそのまま放置しては大変に不幸。論文・レポート提出間際に、これらの不幸によって死の覚悟をするのは、精神衛生上でもよろしくないです。 オンラインストレージサービスな
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
ナウなヤングのためのgithub入門講座 -基本機能からdotfiles管理まで- - tumblr
gitによるバージョン管理 バージョン管理システムはつかってますか？ 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な１日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ayaka Ikezawa - Profile
Route 477(2009-05-13)