サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
私はGitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When inGolang, Do as theGophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (NaotoshiSeo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうがgithub とも親和性高い感ある。 2014-05-30 11:38:51
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
分散バージョン管理を華麗に扱いたい堀口です。GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :oJava やC++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
前回の時点では「gitblameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgitlog -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる
Re: [git pull] drm-nextLinus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) DaveAirlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか >本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
好きなIPA は志賀高原ビールの @soh335 です。 早くビール飲みたいのですが書かないと怒られるので今日は、隣の発明家が作った GitDDL というモジュールについて説明しますね。 （隣の発明家に任せると「GitDDLまじイノベーティブ（完）」としか説明してくれないので） なにするものなの 名前を見て通り、Git でdatabase の schema 管理をするものです。それ以前は、DBIx::Class::Schema::Versioned とかを使っていたようです。 仕組み まず、Git で管理されている schema ファイルを指し示すコミットのハッシュをdatabase 上で管理します。 schema に変更があった場合、このコミットのハッシュが databse 上のものとで差異が生まれます。よってdatabase 上の schema は期待する schema ではな
A interactive Git visualization tool to educate and challenge!
コミットメッセージの1行目は”短い説明” 英数字で50文字以内にすることを推奨します。短すぎてもわかりにくくなるのでいけません。 内容・理由・意味などを知らない相手によくわかるように述べること。 — せつめい【説明】 角川必携 国語辞典 50文字以内の“説明”にしてください。オレオレ語で書かれた自分しかわからないメモにしないでください。 コミットメッセージのスタイル 日本語よりも英語を利用して、行頭に動詞（現在形のみにする）を置くことを推奨します。ある程度、統一されたスタイルは容易にコミットログを理解するための助けとなります。 日本語でコミットメッセージを書くと 決済に不具合があるバグを修正しました メンテナンスモードを追加しました 日本語の場合、動詞を後ろに持ってこないと違和感ある文章になり、最後まで読まないと文章が理解できません。英語でコミットメッセージを書くと Fix a bug
Gitのデフォルトの設定で、diffを見ると パッチの形式で表示される為、 ぶっちゃけ人間が見ると見づらいんですよ、、、 （慣れろ、俺。とは思うけども。 % git diff diff --git a/src/collection/set_and_map/MapSamples.scala b/src/collection/set_and_map/MapSamples.scala index d03a3db..d39ea38 100644 --- a/src/collection/set_and_map/MapSamples.scala +++ b/src/collection/set_and_map/MapSamples.scala @@ -10,7 +10,7 @@ objectMapSamples { println(map("hoge")) // println(map("foo"
git最近、Git について勉強しています。Windows で Git をやるなら Cygwin と msysGit（Git forWindows） がメジャーなようです。Cygwin Git のいいとこ悪いとこCygwin はUTF-8 な日本語ファイル名にも対応しており、Cygwin の中で閉じて Git を使っている分には何不自由なく使えるのでお勧めです。ただし、次のような悲しいポイントがあります。 Cygwin 版 Git は、Windows 向けのGUI な Git ソフト(TortoiseGit や Git Extensions)との相性が悪いWindows のエディタやマージツールと連携しようとするとパスのポリシーが違うのでうまくいかないnkf を噛ませようとしても、Cygwin 用の nkf バイナリは公式配布されておらず、わざわざ Cygwin 上で make す
【翻訳】Gitをボトムアップから理解するJohn Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
