【翻訳】Gitをボトムアップから理解する. 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。 （詳しくは記事内の最初にも書いてあります） Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。 そしてボトムアップ視点で見る Git がこんなにも美しくシンプルであるなら、私が調べたことを他の人も興味を持って読んでくれるのではないか、そうして私が経験した苦労を避けられるのではと考えた。 この文書にある例には、Git 1.5.4.5 を使用している。 目次 ライセンス 導入 リポジトリ：ディレクトリ内容の追跡 blob の紹介 blob は tree が保管する tree はどのように作られるか コミットの美 コミットを別名で言うと… ブランチングと rebase の力 インデックス：仲介者を知ろう 一歩先のインデックス リセットすること、またはリセットしないこと mixed reset の実行 soft reset の実行 hard reset の実行 鎖をつなぐ最後の輪：stash と reflog まとめ 参考文献 1.
この文書は米国クリエイティブ・コモンズライセンス 3.0 の BY-SA 条件下で提供される。 2. Git の世界へようこそ。 本題に入る前にまず、本稿中で繰り返し現れる、触れておくべき用語がいくつかある： repository リポジトリ (repository) はコミットの集合であり、各コミットはプロジェクトにおいて過去に存在したワーキングツリーのアーカイブだ。 The index あなたが使用してきたであろう他の似たツールと違い、Git はワーキングツリーからリポジトリへ変更を直接コミットしない。 Working tree ワーキングツリー (working tree) は、それに関連するリポジトリを持った、ファイルシステム上のあるディレクトリのことだ (普通は中に .git という名前のサブディレクトリが存在することでわかる)。 Commit コミットはある時点でのワーキングツリーのスナップショットだ。 3. 以上のように、Git がすることはかなり原始的だ。 Blobの紹介 そらきた！ 4. Flow (Japanese translation) Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで git-flow についてどう思うかを尋ねられた。 私はいつも、git-flowは素晴らしいと思うと答えている。 何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。 しかしながら、それ故の問題も抱えている。 私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。 クールかもしれないが、GitのGUIツールには強制することができず、コマンドラインでしか使えないという問題がある。 これらの問題点は、手順をもっとシンプルにするだけで容易に解決できる。 そのシンプルさには多くのメリットがある。 GitHub Flow さて、なぜGitHubではgit-flowを使わないのだろうか？
定期的にデプロイを行うことにはいくつかの利点がある。 四六時中デプロイすることのもうひとつの利点は、あらゆる種類の問題を迅速に解決することが可能になる点だ。 すべてが同じプロセスであり、すべてがとてもシンプルだ。 どうやっているのか GitHub Flowとは何だろうか？ Masterブランチのものは何であれデプロイ可能である新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する（例: new-oauth2-scopes）作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushするフィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができるマージをしてmasterへpushしたら、直ちにデプロイをする これがフローのすべてだ。 では、各ステップを順に見て行こう。 #1 - masterブランチのものは何であれデプロイ可能である これが、おおむねこのシステムにおけるたった一つの厳格な ルール である。 #4 - いつでもプルリクエストを作る まとめ. A successful Git branching model を翻訳しました. この記事では、私の全てのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。 しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。 ここでは私のプロジェクトの詳細については書かず、単にリリース管理のブランチ戦略についてだけ述べよう。 ここではソースコードのバージョニングのためのツール、Gitに注目する。 なぜGitか？ 中央管理型のソースコード管理システムと比べて、Gitの長所と短所を徹底的に議論するために、webを見てみよう。
そこではたくさんのディスり合いが続いている。 しかしGitでは、それらの動作は非常に安く簡単で、日常のワークフローの重要な一部と考えられている。 それらの簡潔性と反復的な性質の結果として、ブランチングとマージはもはや恐れるような何かではない。 さてツールについては十分だ、開発モデルに向かおう。 分散、しかし中央集権 私たちが使う、そしてこのブランチングモデルでうまく動かすためにセットアップしたリポジトリは、中央の「本当の」リポジトリがついている。 それぞれの開発者は、 origin から pull または push を行う。 技術的には、これは Alice が bob という名前の、 Bob のリポジトリを指す Git remote を定義した（逆もまた同様）ことを意味する。 メインブランチ 開発モデルのコアを成すのは、多くの既存のモデルたちにとてもインスパイアされたものだ。 ・master ・develop origin の master ブランチは全てのGitユーザーに馴染みがあるはずだ。 Origin/master は、製品として出荷可能な状態を常に反映する、ソースコードの HEAD のありかであるメインブランチだと考える。 Origin/develop は、次のリリースのための最新の開発作業の変更を常に反映する、ソースコードの HEAD のありかであるメインブランチだと考える。
Develop ブランチのソースコードが安定し、リリースの準備ができたとき、 develop ブランチの全ての変更は master ブランチへマージされ、リリース番号をタグ付けされることになる。 したがって、 master へ変更がマージされる時はいつも、その定義からして新しい製品リリースの時だ。 実践 Git - 低レベルに知る Git. 図解 Git. もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 Git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。 このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。 (日本語訳の GitHub リポジトリ) 内容 基本的な使い方 上記4つのコマンドは、作業ディレクトリ、ステージ(インデックスとも呼ばれる)、および履歴(一連のコミット)間でファイルをコピーします。 Git add files は files (の現在の状態)をステージにコピーします。 ファイルを特定しないで(あるいはファイルに加えて)、git reset -p、git checkout -p、あるいは git add -p を使えば、対話的にどのハンクを対象にするのか選べます。
凡例 これ以降、以下のような図を使っていきます。 緑色はコミットで、5文字の識別子が付いており、自分の親を指しています。 コマンドの詳細 Diff 差分を取る方法は、たくさんあります。 Commit コミットを実行すると、git はステージングされたファイルから、新しいコミットオブジェクトを作り、その親として最新のコミットを設定します。 たとえ、現在のブランチが中間のコミット(あるコミットの親であるコミット)であっても、同じことが起きます。 ときどき、間違ったコミットを実行してしまうこともあるでしょう。 4番目の使い方は 分離HEADへのコミットですが、これについては後述します。 Checkout checkout コマンドは、履歴(またはステージ)から作業ディレクトリへファイルをコピーするために使います。 ファイル名(と加えて-pと)が与えられると、git は指定されたファイルを指定されたコミットからステージと作業ディレクトリへコピーします。 分離HEADでの commit HEAD が分離されている場合、名前のついたブランチは何も更新されないという点を除いて、commit は通常と同じ動作をします。 ぼくが実際に運用していたGitブランチモデルについて. ブランチモデル オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。 淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。
ですが、完全ではありません。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。 ここで述べるようなブランチモデルは、製品やサービスなど、現在顧客に提供している安定化されたビルドと今後必要な機能をそなえた先進的なビルドを、区別して運用したいケースが主といえるでしょう。 この2つをハッキリと区別して管理できるのは重要で、目前の小さなfixを短期のイテレーションでデリバリーすることと、将来的に必要な機能を意欲的にディベロップすることの2つの両立するための運用負荷を下げることができます。 短期イテレーションで走り続けて、バグ発生の可能性が高いリスキーな機能追加まで短期の中に織り込まれると、（人員が潤沢ならともかく基本的には）相当しんどいです('A`) 基本的な役者 さて、A successful Git branching modelによるものですが、私の運用していたブランチ群には、以下のような役者がおりました。 これらのブランチには、絶対になくてはならないブランチと、省略しても平気なブランチに分けることができたりします。 1. まずは無くてはならない彼ら。 Masterブランチ 命名規則（固定） master 出荷されうる完全な品質を保証する特定のブランチからマージすることによってしか更新されない直接コミットしてはならないという制約をもつバージョンごとのtagはここから生まれる 当たり前のようにmasterブランチは基本ですが、このブランチモデルにおけるmasterは、開発の主軸ではありません。 ようは、サービスなら現在本番サーバに鎮座しているもの、製品であれば現在配布しているもの、そういうことです そのため開発者による直接的なコミットはされません。 また、各バージョンの完全な状態を残すためのtagはここから生まれます。 Developブランチ 命名規則 2. 参考. アジャイルSEを目指すブログ. リリカルハッカソンでDVCS(veracity, fossil)を触ってみた 3 #nanohack veracityでプロジェクトを作ってみた。
参考ページ I've installed Veracity. How do I get started using it? - Veracity Q&A コマンド簡易まとめ ちなみに、veracityは[TAB]でコマンドの補完が効いた。 プロジェクトの作成 mkdir lyrical_tokyo cd lyrical_tokyo vv init lyrical_tokyo . ユーザの設定 $ vv whoami --create sinsoku_listy[at]gmail.com ファイルを追加する $ touch README $ vv status Found: @/README $ vv add README 1 added 変更をコミットする $ vv commit -m "add README" revision: 2:bc67e711d9acbe3e9e7b87fcb79d62828b673d56 branch: master who: sinsoku_listy[at]gmail.com when: 2013/04/13 17:46:22.955 +0900 comment: add README parent: 1:08fae75af4ed7b230c3d29e34c175649a84a1416 ブラウザで表示する $ vv serve こんな感じの画面が表示される。
リリカルハッカソンでDVCS(veracity, fossil)を触ってみた 2 #nanohack fossil でプロジェクトを作ってみた Fossil: Fossil Quick Start Guide ちなみに[TAB]でのコマンドの補完が効かないので、結構不便 新しいリポジトリを作成する リポジトリをcloneして、作業ディレクトリを作成する ブランザでの表示. Gitのブランチで効率的に開発・運用・保守・管理する方法 - (DxD)∞ 分散バージョン管理システム「Git」のブランチ機能を利用して、効率的に開発・運用・保守・管理する方法を「A successful Git branching model」(日本語訳)をベースにまとめてみました。 はじめに 最初に、Gitに関するリソースとして、本では「入門Git」と「実用Git」、Web上では「Pro Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。 特に、他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。 実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。 しかし、Gitを利用していくにつれて色々と疑問も出てきます。 A successful Git branching model Gitでの開発・運用の疑問に答えてくれる一つのモデルがあります。
要約すると、タグ付け専用のブランチ(master)と開発用のブランチ(develop)を用意し、通常の開発やリリースの準備はdevelopブランチをベースに、リリースやホットフィックスはmasterブランチをベースに行うというものです。 大規模な運用でなければ、このモデルでほとんどのケースに対応できるかと思います。 新たな疑問 実際の運用に「A successful Git branching model」を当てはめて考えた場合、細かい部分で次のような新たな疑問も湧いてきました。 ホットフィックス(緊急性の高いバグの修正)以外のバグフィックスはどのように行うか？ これらの疑問を解決するために、「A successful Git branching model」周りのリソースや他のGitに関するリソースを参考にして、「A successful Git branching model」のブランチグラフと開発・運用シナリオを掘り下げてまとめてみました。 (上記は、「A successful Git branching model」のブランチグラフをベースに、いくつかのブランチ群とシナリオを追加、一部の説明とレイアウトを調整したものです。 マージオプション(mergeoptions)を指定する方法 参考 まとめ. Git ユーザマニュアル (バージョン 1.5.3 以降用) Gitによるバージョン管理入門 for windows.
複数リポジトリの関係 複数リポジトリが関係してくると、ブランチがなんだかとても分かりにくくなります。 マニュアルや解説を見ても何か分かったような、分からないような感じがすることが多いです。 それは、主に２つの誤解と、リモートがらみのブランチの意味や機能や名前の混乱のせいです。 （と言うか、私が、最初わからなくて、後で「あっ！ そういう事か！」 と分かった事ですが。。。 誤解の1つ目は、プッシュやプルを実行すると、何か「魔法の同期」が行われて、リポジトリ全体が同じ状態になるのだ、という誤解です。 誤解の２つ目は、同じ名前のブランチは、リポジトリ間で「共有」されている、という誤解です。 Gitの練習で最初に使うことになるmasterブランチは、プッシュやプルでリモートに送ったり、逆に取り込んだりが簡単に出来るので、リポジトリ間で同じ名前のブランチに何か特別の関係があるように見えますが、実はこれは、単に「ブランチ間のマージ」をしているだけなのです。 「リモートがらみのブランチの意味や機能や名前の混乱」とは何かと言うと、これがなかなか言葉では説明しづらい上に、名前がどうも統一されていない、と言うか、色々調べたんですが、ちゃんと名前がついていないような感じなんです。 XSystem.git リポジトリ ⑦ <-- develop ／ ① -- ② -- ⑤ <-- *master ＼ ③ -- ④ -- ⑥ <-- test これをIchiroの下にクローンすると、 Ichiro/XSystem リポジトリ remotes/origin -> XSystem.git ⑦ <-- origin/develop ／ ① -- ② -- ⑤ <-- *master origin/master ＼ ③ -- ④ -- ⑥ <-- origin/test この様に、XSystem.gitがoriginと言う名前でリモートリポジトリとして登録されているリポジトリが出来ます。
XSystem.gitからすべてのコミットがコピーされ、masterブランチはクローン元と同じ状態になります。 Git Guiを良く使うので、われわれはこれをトラッキング・ブランチと呼ぶことにしましょう。 このトラッキング・ブランチは、チェックアウトして更新したり、コミットしたりしてはいけない特別なブランチです。 コミット⑧が増えました。 Book. たのしいGit - Nalsh's Notes. 【翻訳】あなたの知らないGit Tips. Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る $ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current dir is not "hub" 494a414 fix cherry-pick of a commit URL 4277848 (origin/master, origin/HEAD, master) whoops d270fae bugfix: git init -g 9307af3 test deps 8ccc17e 64bb19c bugfix: variable name 546726a dont need you 3a8d7af (tag: v1.3.1) v1.3.1 197f429 (tag: v1.3.0) v1.3.0 a1e1a50 not important 3c6af16 magic `cherry-pick` supports GitHub commit URLs and "user@sha" notation diff で行の全てではなく、変更された単語部分のみハイライトする $ git diff --word-diff # Returns a Boolean. def command?
このオプションは git log -p や git show などの、diff のためのオプションを使えるところなら動作する。 短い status 出力 $ git status -sb 他人のリモートブランチを簡単に追跡する. イラストでわかる！git入門の入門. こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット？ ジット？ 俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの？ なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは？ バージョン管理ってなに？ プログラムを書いていて、こんなことありませんか？ ・修正前は動いていたのに！ 戻りたい！ バージョン管理をするには？ じゃあその、バージョン管理をするには何が必要でしょうか？
ですが、現在はgit（ギット）が主流です。 GitはLinuxカーネルの開発にも使われているのです。 Subversionとは ではgitについて勉強する前に、Subversionについて触れておきましょう。 Subversionとは、集中型バージョン管理システムという分類にあたるシステムです。 ここで、不明な単語「リポジトリ」について説明します。 また、「コミット」というのは、ドラクエでいう「セーブ」のことです。 このコミットは、機能ごとに行うことが多いです。 Subversionのデメリット Subversionには、中央集中だからこそ起こるいろいろなデメリットがあります。 代表的なものが、サーバに接続できない環境だと、最新のソースコードが取得できないというものです。 また、他者から編集されるのを防ぐロック機能があるとご説明しましたが、 ロックしたまま放置されると、その間誰もそのファイルを編集できなくて不便です。 Gitとは ここで、gitの出番です！ 自分のPC上、ローカル環境で編集して、自分のリポジトリにコミットしていきます。 複数人での開発 gitを使って複数人で開発するときはこんなかんじです。
(3)の、マージというのがイメージしづらいかもしれません。 ポケモンでいうと、サトシがイッシュ地方でポケモンを捕まえたセーブデータ（コミット内容）があり、 タケシがジョウト地方でポケモンを捕まえたセーブデータ（コミット内容）があるという状態を想像してください。 便利ですね！ Gitプロジェクト作成. Gitの基礎練習. Git - 簡単ガイド. Git - 簡単ガイド 猫でもわかるGit 最初の一歩 Roger Dudler (著) @nacho4d (訳) クレジット @tfnico, @fhd, Namics その他の言語 english, deutsch, español, français, italiano, nederlands, português, русский, türkçe, မြန်မာ, 中文, 한국어 問題などの報告はgithubでお願いします。 設定 OSX用 Gitをダウンロード Windows用 Gitをダウンロード Linux用 Gitをダウンロード リポジトリの作成 新規のリポジトリを作成するには 新しいフォルダを作って開きます。 リポジトリのチェックアウト ローカルのリポジトリをクローンするには git clone /path/to/repository そして、リモートのリポジトリをクローンするには git clone username@host:/path/to/repository を実行します。 作業の流れ ローカルのリポジトリはGitが管理する三本の"木"からなっています。 アッド & コミット 変更されたファイルを選択します。
変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。 ブランチ ブランチは関連性のない機能を実装するときに使用されるもので、リポジトリを作成する際にデフォルトのブランチはmasterです。 "feature_x"という名前のブランチを作って スイッチします git checkout -b feature_x メインのブランチに戻る git checkout master ブランチの削除 git branch -d feature_x ブランチをリモートリポジトリにプッシュしない限りブランチは他人には見れないようになっていますのでご注意ください。 アップデート & マージ 自分のリポジトリを最新のコミットにアップデートするには git pull を作業のフォルダで実行するとリモートリポジトリの最新情報を取得し(fetch)現在の状態とマージ(merge)されます。 タグ SVNでも使用されている概念ですが、バージョンをリリースする度にタグを作る事が推奨されています。 変更の取り消し 便利なコマンド その他のリンクと資料 グラフィッククライアント. こわくない Git. Git を学ぶための日本語ドキュメント一覧 #git. サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ.