Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck

GitHub Kaigiに行って来た。 なんだかよくわからないのだけど、500名定員の勉強会みたいなものというのもすごいし、キャンセル待ちがさらに500名くらいいるというのもすごい。なんでこんなに人が集まるのだ、という位、すごい人である。 昔、SourceForgeつーのがあってだねというようなことを言うのは間違いなく老人なのであるが、SourceForgeって同じようなことができるのになんでGitHubだけがこんなにもてはやされるのだろう。なぞである。 多分、ステッカーの影響もでかいと思う。 ギークな人たちはMacにGitHubのステッカーはっているよね。おしゃれな感じがするつーことっすか。gitコマンドの一つもたたけないとモテないっすかね。 みたいなことをつらつら思ったのだけど、分散リポジトリというのがカジュアルに使える、使うのが当たり前になったというのは、すごいことだと思った。それが

ともちゃんがGitHubを勉強したいにゃん、ということなので、勉強会に行ってきた。みんな猫耳つけて発表するというわけのわからない勉強会であった。 http://atnd.org/events/48075 Introduction to Git and GitHub #git_nyan from Hiro Yoshioka のれんがかかっていた。 これらはすべて手作り 沢田さんの説明 LTもあった GitHub実践入門とステッカー わたしのお話は、GitがLinusの自分の問題を解決することから始まったというような歴史の話からあれやこれや。Linuxのソースコードを管理するためには分散型、高速、高信頼性などが必要。 Linusは自分のPCのバックアップをとっていなくてもコミットしたものをインターネットにおいておけば誰かがコピーして、そのコピーは改竄することが非常に難しいので安全に複数のバック

みんなでGitHubを勉強するにゃんっ！に参加するのでいろいろGitとかGitHubについて再勉強ちう。 そしたらGitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)を著者の大塚さんから送付いただいた。読了。ありがとうございます。 目次をみるとなかなかよさげだったので、期待しながら読んだ。素晴らしい。 http://gihyo.jp/magazine/wdpress/plus/978-4-7741-6366-6/0001 第1章GitHubの世界へようこそ 第2章Gitの導入 第3章GitHubを利用するための準備 第4章Gitを操作しながら学ぶ 第5章GitHubの機能を徹底解説 第6章はじめてのPull Request 第7章Pull Requestが送られてきたら 第8章GitHubと連携するツールとサービス 第9章GitHubを利

http://d.hatena.ne.jp/hyoshiok/20140205/p1 集中型バージョン管理システムと分散型バージョン管理システムってでいろいろコメントをいただく。ありがとうございます。 結局、学習コストの話になる。何事もなれですね、そーですね。では、さすがに何を議論しているかわからなくなる。 前提として、ソフトウェア製品とかサービス開発の現場のエンジニアの素養としてのVCS利用スキルをどう身につけるかということに限定してみたい。プロのプログラマの必須スキルということを考えている。 サンデープログラマが趣味でプログラムを作っているとかではなく、職業としてソフトウェア製品とかサービスを開発する人のことだ。 そのような人を養成する授業を大学が用意するとしたらどのようなカリキュラムになりうるのか？ ソフトウェア開発の現場の経験がないけど、プログラミング経験くらいはある。エディタは使

下記で見つけた各バージョン管理システム(VCS)のコマンドの比較表。 http://japan.blogs.atlassian.com/2012/03/mercurial-vs-git-why-mercurial/ Subversion (SVN) Mercurial (Hg) Git svn add hg add git add svn blame hg blame git blame svn cat hg cat git show svn checkout hg clone git clone svn commit hg commit ; hg push git commit -a ; git push svn delete/remove hg remove git rm svn diff hg diff git diff, git diff –cached svn help hg h

いろいろな人がgitは難しいという。そうなのかなー。ふーん。自分はあんまりそうは思わないけどつらつらと考えてみた。（無駄に長いし、有意義なことを書いてあるわけではないので、お急ぎの人はスルーしちゃってください） 前提として、分散バージョン管理システムを使うケースというのは、複数の人が共同でソフトウェアなどを作るという状況のときだ。管理の対象は通常ファイルになる。複数の人が同じところにいるという必要はないけど、別に同じ場所にいてもいい。「分散」というぐらいだから、インターネットさえ繋がっていれば、地球の裏側でもいいし、火星から共同開発をしてもかまわない。そーゆー前提でソフトウェアを開発するとする。 それのレポジトリをどこに置くかという問題は、社内のどっかのサーバーでもいいし、自分のPCでもいいし、インターネット経由でコラボレーションをするのならgithubみたいなサービスを使うというのでもい

例えば以下のようにローカルにgitで管理していて、ふとgithubあたりで公開したくなったとする。はじめからgithubにレポジトリを持っていた場合は、それを $ git clone して、ローカルでごにょごにょして $ git push すればいいのだけど、その順番が逆の場合。 $ git init $ git add . $ git commit -m "initial commit" ... ここで、あー、githubにpushしたいなーとふと思う。 おもむろにgithubにsign inしてrepositoryをnewする。仮にユーザ名がuser-nameでリポジトリがrepositoryというのを作ったすると、ローカルからのpushは下記のような感じになる。 $ git remote add origin git@github.com:user-name/repository 最

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗

Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du

06:32 pm - 入門Gitの目次はというと 先般書き上げたgit本の カバーのコピーを貰った。 せっかくだからここに貼ってみる。 目次はというと、こんな具合である。 gitとはgitの基本概念インストールと初期構成独りで使う2か所で使うグループで使うブランチを使った開発分散環境とブランチとの関連変更履歴を追いかけるパッチ・べースのワークフローゴミファイルの無視構成変数リモート・リポジトリ定義ファイル・アトリビュート歴史の2分探索間違いからの回復フック・メカニズムリポジトリの出版公開gitの周辺上の目次より前に、Linus君の「はしがき」を英和対訳でつけている。 最初の第一章と第二章では、どのgit入門本でも書かないといけない決まりになっている「ファイルもディレクトリもコミットも、その内容を表すデータのSHA-1ハッシュでオブジェクト名を付けて格納します」なんてのももちろん出て来るけれ

ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB

入門GitはGitのメンテナである濱野さんが書いただけあってGitの本質がわかりやすく記されている。 バージョン管理システム(VCS--Version Control System)としてCVSやSubversion(SVN)があるし、分散型VCSとしては、Git以外にもいろいろあるが、まあGitでいいのではないかと。なんといってもLinuxで利用されているという圧倒的な実績。数千人規模のプロジェクトで利用できるスケーラビリティ。そのような規模では、もはやSVNのような集中型VCSではスケールしないというのはあきらかだろう。 VCSの解説は、細かい機能というよりも、そのツールを利用してのプロセスやワークフローあるいは利用しているコミュニティの文化なんていうものを、わたしは理解したいので、その意味で本書は濱野さんの経験からでる貴重なノウハウがつまっている。 Gitなどを使った共同開発の基本的

はてぶとか見ていると、すげー上から目線の人がいて、あああ、こーゆー人達って、何様？とか思ってしまう。あ、俺様かあ、なるほど。 デブサミのコミュニティLTの裏番組で、株式会社はてなの開発戦略*1というのがあって、わたしも司会なんかしていなかったら、聞きにいきたかったセッションなのだけど、それが予想にたがわず、素晴しいものだったということは、皆さんのブログの感想戦などを拝見していると思ったりする。 gitいいよねgitという内容なのか、そうでないかは現場にいなかったので微妙な空気まではわからない。git移行のきっかけが、SVNのリポジトリの崩壊、瓦解、というのがほほえましくもあり、ツッコミどころでもあり。 はてぶのコメントで http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/rx7/20090212/p1 なんかで、エラソーに言っている人がいる