Skip to content

Commit 4139042

Browse files
dschodscho
dscho
authored and
dscho
committed
Merge branch 'book-ja' of bundle-ja/ja.bundle into hugo
2 parents 1312fd1 + f000997 commit 4139042

File tree

874 files changed

+26916
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

874 files changed

+26916
-0
lines changed

‎external/book/content/book/ja/_index.html‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
---
2+
### DO NOT EDIT! Generated by script/update-book2.rb
3+
redirect_to: book/ja/v2
4+
---

‎external/book/content/book/ja/v2/Git-での分散作業-まとめ.html‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
### DO NOT EDIT! Generated by script/update-book2.rb
3+
category: book
4+
section: documentation
5+
subsection: book
6+
sidebar: book
7+
book:
8+
language_code: ja
9+
chapter:
10+
title: Git での分散作業
11+
number: 5
12+
section:
13+
title: まとめ
14+
number: 4
15+
cs_number: '5.4'
16+
previous: book/ja/v2/Git-での分散作業-プロジェクトの運営
17+
next: book/ja/v2/GitHub-アカウントの準備と設定
18+
title: Git - まとめ
19+
url: "/book/ja/v2/Git-での分散作業-まとめ.html"
20+
---
21+
<h2 id="_まとめ_6">まとめ</h2>
22+
<div class="paragraph">
23+
<p>Git を使っているプロジェクトにコードを提供したり、自分のプロジェクトに他のユーザーからのコードを取り込んだりといった作業を安心してこなせるようになりましたね。
24+
おめでとうございます。Git を使いこなせる開発者の仲間入りです!
25+
次の章では、世界最大で一番人気の Git ホスティングサービス、GitHub の使い方を見ていきましょう。</p>
26+
</div>
27+
<div id="nav"><a href="{{< previous-section >}}">prev</a> | <a href="{{< next-section >}}">next</a></div>

‎external/book/content/book/ja/v2/Git-での分散作業-プロジェクトの運営.html‎

Lines changed: 691 additions & 0 deletions
Large diffs are not rendered by default.

‎external/book/content/book/ja/v2/Git-での分散作業-プロジェクトへの貢献.html‎

Lines changed: 945 additions & 0 deletions
Large diffs are not rendered by default.

‎external/book/content/book/ja/v2/Git-での分散作業-分散作業の流れ.html‎

Lines changed: 166 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,166 @@
1+
---
2+
### DO NOT EDIT! Generated by script/update-book2.rb
3+
category: book
4+
section: documentation
5+
subsection: book
6+
sidebar: book
7+
book:
8+
language_code: ja
9+
chapter:
10+
title: Git での分散作業
11+
number: 5
12+
section:
13+
title: 分散作業の流れ
14+
number: 1
15+
cs_number: '5.1'
16+
previous: book/ja/v2/Gitサーバー-まとめ
17+
next: book/ja/v2/Git-での分散作業-プロジェクトへの貢献
18+
title: Git - 分散作業の流れ
19+
url: "/book/ja/v2/Git-での分散作業-分散作業の流れ.html"
20+
---
21+
<p></p><p>リモート Git リポジトリを用意し、すべての開発者がコードを共有できるようになりました。また、ローカル環境で作業をする際に使う基本的な Git コマンドについても身についたことでしょう。次に、Git を使った分散作業の流れを見ていきましょう。</p><p>本章では、Git を使った分散環境での作業の流れを説明します。
22+
自分のコードをプロジェクトに提供する方法、そしてプロジェクトのメンテナーと自分の両方が作業を進めやすくする方法、そして多数の開発者からの貢献を受け入れるプロジェクトを運営する方法などを扱います。</p>
23+
<h2 id="_分散作業の流れ">分散作業の流れ</h2>
24+
<div class="paragraph">
25+
<p></p>
26+
</div>
27+
<div class="paragraph">
28+
<p>中央管理型のバージョン管理システム (Centralized Version Control System: CVCS) とは違い、Git は分散型だという特徴があります。この特徴を生かすと、プロジェクトの開発者間での共同作業をより柔軟に行えるようになります。
29+
中央管理型のシステムでは、個々の開発者は中央のハブに対するノードという位置づけとなります。
30+
しかし Git では、各開発者はノードであると同時にハブにもなり得ます。つまり、誰もが他のリポジトリに対してコードを提供することができ、誰もが公開リポジトリを管理して他の開発者の作業を受け入れることもできるということです。
31+
これは、みなさんのプロジェクトや開発チームでの作業の流れにさまざまな可能性をもたらします。本章では、この柔軟性を生かすいくつかの実例を示します。
32+
それぞれについて、利点だけでなく想定される弱点についても扱うので、適宜取捨選択してご利用ください。</p>
33+
</div>
34+
<div class="sect3">
35+
<h3 id="_中央集権型のワークフロー">中央集権型のワークフロー</h3>
36+
<div class="paragraph">
37+
<p></p>
38+
</div>
39+
<div class="paragraph">
40+
<p>中央管理型のシステムでは共同作業の方式は一つだけです。それが中央集権型のワークフローです。
41+
これは、中央にある一つのハブ (リポジトリ) がコードを受け入れ、他のメンバー全員がそこに作業内容を同期させるという流れです。
42+
多数の開発者がハブにつながるノードとなり、作業を一か所に集約します。</p>
43+
</div>
44+
<div class="imageblock">
45+
<div class="content">
46+
<img src="{{< relurl "book/ja/v2/images/centralized_workflow.png" >}}" alt="中央集権型のワークフロー">
47+
</div>
48+
<div class="title">図 53. 中央集権型のワークフロー</div>
49+
</div>
50+
<div class="paragraph">
51+
<p>二人の開発者がハブからのクローンを作成して個々に変更をした場合、最初の開発者がそれをプッシュするのは特に問題なくできます。
52+
もう一人の開発者は、まず最初の開発者の変更をマージしてからサーバーへのプッシュを行い、最初の開発者の変更を消してしまわないようにします。
53+
この考え方は、Git 上でも Subversion (あるいはその他の CVCS) と同様に生かせます。そしてこの方式は Git でも完全に機能します。</p>
54+
</div>
55+
<div class="paragraph">
56+
<p>小規模なチームに所属していたり、組織内で既に中央集権型のワークフローになじんでいたりなどの場合は、Git でその方式を続けることも簡単です。
57+
リポジトリをひとつ立ち上げて、チームのメンバー全員がそこにプッシュできるようにすればいいのです。Git は他のユーザーの変更を上書きしてしまうことはありません。
58+
たとえば、John と Jessica が作業を一斉に始めたとしましょう。
59+
先に作業が終わった John が、変更をサーバーにプッシュします。
60+
次に、Jessica が変更をプッシュしようとすると、サーバー側でそのプッシュは拒否されます。
61+
そして Jessica は、直接プッシュすることはできないのでまずは変更内容をマージする必要があることを Git のエラーメッセージから気づきます。
62+
この方式は多くの人にとって魅力的なものでしょう。これまでにもなじみのある方式だし、今までそれでうまくやってきたからです。</p>
63+
</div>
64+
<div class="paragraph">
65+
<p>また、この例は小規模なチームに限った話ではありません。Git のブランチモデルを用いてひとつのプロジェクト上にたくさんのブランチを作れば、何百人もの開発者が同時並行で作業を進めることだってできるのです。</p>
66+
</div>
67+
</div>
68+
<div class="sect3">
69+
<h3 id="r_integration_manager">統合マネージャー型のワークフロー</h3>
70+
<div class="paragraph">
71+
<p></p>
72+
</div>
73+
<div class="paragraph">
74+
<p>Git では複数のリモートリポジトリを持つことができるので、書き込み権限を持つ公開リポジトリを各自が持ち、他のメンバーからは読み込みのみのアクセスを許可するという方式をとることもできます。
75+
この方式には、「公式」プロジェクトを表す公式なリポジトリも含みます。
76+
このプロジェクトの開発に参加するには、まずプロジェクトのクローンを自分用に作成し、変更はそこにプッシュします。
77+
次に、メインプロジェクトのメンテナーに「変更を取り込んでほしい」とお願いします。
78+
メンテナーはあなたのリポジトリをリモートに追加し、変更を取り込んでマージします。そしてその結果をリポジトリにプッシュするのです。
79+
この作業の流れは次のようになります ( <a href="{{< relurl "book/ja/v2/ch00/rwfdiag_b" >}}">統合マネージャー型のワークフロー</a> を参照ください)。</p>
80+
</div>
81+
<div class="olist arabic">
82+
<ol class="arabic">
83+
<li>
84+
<p>プロジェクトのメンテナーが公開リポジトリにプッシュする</p>
85+
</li>
86+
<li>
87+
<p>開発者がそのリポジトリをクローンし、変更を加える</p>
88+
</li>
89+
<li>
90+
<p>開発者が各自の公開リポジトリにプッシュする</p>
91+
</li>
92+
<li>
93+
<p>開発者がメンテナーに「変更を取り込んでほしい」というメールを送る</p>
94+
</li>
95+
<li>
96+
<p>メンテナーが開発者のリポジトリをリモートに追加し、それをマージする</p>
97+
</li>
98+
<li>
99+
<p>マージした結果をメンテナーがメインリポジトリにプッシュする</p>
100+
</li>
101+
</ol>
102+
</div>
103+
<div id="rwfdiag_b" class="imageblock">
104+
<div class="content">
105+
<img src="{{< relurl "book/ja/v2/images/integration-manager.png" >}}" alt="統合マネージャー型のワークフロー">
106+
</div>
107+
<div class="title">図 54. 統合マネージャー型のワークフロー</div>
108+
</div>
109+
<div class="paragraph">
110+
<p></p>
111+
</div>
112+
<div class="paragraph">
113+
<p>これは GitHub や GitLab のようなハブ型のツールでよく使われている流れです。プロジェクトを容易にフォークでき、そこにプッシュした内容をみんなに簡単に見てもらえます。
114+
この方式の主な利点の一つは、あなたはそのまま開発を続行し、メインリポジトリのメンテナーはいつでも好きなタイミングで変更を取り込めるということです。
115+
変更を取り込んでもらえるまで作業を止めて待つ必要はありません。自分のペースで作業を進められるのです。</p>
116+
</div>
117+
</div>
118+
<div class="sect3">
119+
<h3 id="_独裁者と副官型のワークフロー">独裁者と副官型のワークフロー</h3>
120+
<div class="paragraph">
121+
<p></p>
122+
</div>
123+
<div class="paragraph">
124+
<p>これは、複数リポジトリ型のワークフローのひとつです。
125+
何百人もの開発者が参加するような巨大なプロジェクトで採用されています。有名どころでは Linux カーネルがこの方式です。
126+
統合マネージャーを何人も用意し、それぞれにリポジトリの特定の部分を担当させます。彼らは副官 (lieutenant) と呼ばれます。
127+
そしてすべての副官をまとめる統合マネージャーが「慈悲深い独裁者 (benevalent dictator)」です。
128+
独裁者のリポジトリが基準リポジトリとなり、すべてのメンバーはこれをプルします。
129+
この作業の流れは次のようになります ( <a href="{{< relurl "book/ja/v2/ch00/rwfdiag_c" >}}">慈悲深い独裁者型のワークフロー</a> を参照ください)。</p>
130+
</div>
131+
<div class="olist arabic">
132+
<ol class="arabic">
133+
<li>
134+
<p>一般の開発者はトピックブランチ上で作業を進め、<code>master</code> の先頭にリベースする。独裁者の <code>master</code> ブランチがマスターとなる</p>
135+
</li>
136+
<li>
137+
<p>副官が各開発者のトピックブランチを自分の <code>master</code> ブランチにマージする</p>
138+
</li>
139+
<li>
140+
<p>独裁者が各副官の <code>master</code> ブランチを自分の <code>master</code> ブランチにマージする</p>
141+
</li>
142+
<li>
143+
<p>独裁者が自分の <code>master</code> をリポジトリにプッシュし、他のメンバーがリベースできるようにする</p>
144+
</li>
145+
</ol>
146+
</div>
147+
<div id="rwfdiag_c" class="imageblock">
148+
<div class="content">
149+
<img src="{{< relurl "book/ja/v2/images/benevolent-dictator.png" >}}" alt="慈悲深い独裁者型のワークフロー">
150+
</div>
151+
<div class="title">図 55. 慈悲深い独裁者型のワークフロー</div>
152+
</div>
153+
<div class="paragraph">
154+
<p>この手のワークフローはあまり一般的ではありませんが、大規模なプロジェクトや高度に階層化された環境では便利です。
155+
プロジェクトリーダー (独裁者) が大半の作業を委譲し、サブセット単位である程度まとまってからコードを統合することができるからです。</p>
156+
</div>
157+
</div>
158+
<div class="sect3">
159+
<h3 id="_ワークフローのまとめ">ワークフローのまとめ</h3>
160+
<div class="paragraph">
161+
<p>Git のような分散システムでよく使われるワークフローの多くは、実社会での何らかのワークフローにあてはめて考えることができます。
162+
これで、どのワークフローがあなたに合うかがわかったことでしょう (ですよね?)。
163+
次は、より特化した例をあげて個々のフローを実現する方法を見ていきましょう。</p>
164+
</div>
165+
</div>
166+
<div id="nav"><a href="{{< previous-section >}}">prev</a> | <a href="{{< next-section >}}">next</a></div>

0 commit comments

Comments
 (0)