git-workflow.md 10.3 KB
Newer Older
1 2 3 4
Yii 2 寄稿者のための Git ワークフロー
=====================================

Yii の開発に寄稿したい、ですって? すばらしい! けれども、あなたの修正案が速やかに採用されるチャンスを増やすためには、
5 6 7
以下のステップを踏むようにしてください (最初の二つのステップは最初に寄稿するときにだけ必要になります)。
あなたが git と github については初めてだという場合は、最初に [github help](http://help.github.com/)[try git](https://try.github.com) を精査したり、
[git internal data model](http://nfarina.com/post/9868516270/git-is-simpler) についていくらか学習したりする必要があるかもしれません。
8 9 10 11 12 13 14 15 16 17

### 1. github で Yii リポジトリを [Fork](http://help.github.com/fork-a-repo/) し、あなたのフォークをあなたの開発環境にクローンする

```
git clone git@github.com:YOUR-GITHUB-USERNAME/yii2.git
```

Linux において、GitHub で GIT を設定するのに問題が生じたり、"Permission Denied (publickey)" のようなエラーが発生したりする場合は、
[setup your GIT installation to work with GitHub](http://help.github.com/linux-set-up-git/) に従ってください。

18
### 2. メインの Yii リポジトリを "upstream" という名前でリモートとして追加する
19

20
Yii をクローンしたディレクトリ、通常は "yii2" に入ります。そして、以下のコマンドを打ち込みます:
21 22 23 24 25

```
git remote add upstream git://github.com/yiisoft/yii2.git
```

26
### 3. あなたが取り組んでいる問題が、修正するために著しい努力を要求するものである場合は、それに対する課題(issue)が作成されていることを確認する
27

28
全ての新機能とバグ修正は、議論とドキュメントのための単一の参照ポイントを提供するために、それに結びつく課題を持つべきです。
29 30 31
数分間時間を取って、既存の課題リストに目を通し、あなたが寄稿しようとしている問題に合致するものが無いかどうか調べてください。
もし課題リストにすでに挙っているのを見つけた場合は、その課題にコメントを残して、あなたがその項目について取り組もうとしていることを示してください。
あなたが取り組もうとしている問題に合致する既存の課題が見つからなかった場合は、新しい課題を作成してください。単純な修正であれば、直接にプルリクエストをしてください。
32 33
こうすることで、開発チームはあなたの提案をレビューし、将来にわたって適切なフィードバックを提供することが可能になります。

34
> 小さな変更や、ドキュメントの問題、または単純な修正については、課題を作成する必要はありません。それらについては、プルリクエストだけで十分です。
35 36 37 38 39 40 41

### 4. メインの Yii ブランチから最新のコードをフェッチする

```
git fetch upstream
```

42
最新のコードに対して作業することを保証するために、すべての新しい寄稿においてこのステップから作業を開始すべきです。
43 44 45 46 47

### 5. 現在の Yii のマスターブランチに基いて、あなたの寄稿のための新しいブランチを作成する

> これは非常に重要です。なぜなら、master ブランチを使うと、あなたのアカウントからは一つ以上のプルリクエストを送信することが出来なくなるからです。

48
独立したバグ修正や変更は、各々、それ自身のブランチに入れるべきです。
49 50
ブランチの名前は説明的なものにし、あなたのコードが関係する課題の番号で始まるようにしてください。
特定の課題を修正するものでない場合は、番号を省略してください。
51
例えば、
52 53 54 55 56 57

```
git checkout upstream/master
git checkout -b 999-name-of-your-branch-goes-here
```

58
### 6. あなたの魔法を使って、あなたのコードを書く
59 60 61 62

動くことを確認してくださいね :)

ユニットテストは常に歓迎されます。テストされ、十分にカバーされたコードは、あなたの寄稿をチェックするタスクを非常に単純化してくれます。
63
ユニットテストの失敗を中身とする課題を立てることも許容されています。
64 65 66 67

### 7. CHANGELOG を更新する

CHANGELOG ファイルを編集して、あなたの修正を追加します。
68
新しい行は、ファイル冒頭の "Work in progress" 見出しの下に挿入してください。
69
チェンジログの行は、下記のどちらかのように書いてください。
70 71 72 73 74 75

```
Bug #999: バグ修正の内容説明 (あなたの名前)
Enh #999: 機能拡張の内容説明 (あなたの名前)
```

76 77
`#999``Bug` または `Enh` が参照している課題番号です。
チェンジログは、タイプ (`Bug`, `Enh`) によってグループ化し、課題番号順に並べます。
78

79
非常に小さな修正、すなわち、タイポやドキュメントの修正については、CHANGELOG を更新する必要はありません。
80 81 82

### 8. 修正をコミットする

83
以下のコマンドを使って、コミットしたいファイルや変更を [staging area](http://gitref.org/basic/#add) に追加します。
84 85 86 87 88 89 90

```
git add path/to/my/file.php
```

`-p` オプションを使って、コミットに含める変更を選択することも出来ます。

91 92
説明的なコミットメッセージを付けて修正をコミットしてください。
github があなたのコミットを自動的にチケットとリンクするように、必ず `#XXX` でチケット番号に言及してください。
93 94

```
95
git commit -m "#42 を解決する変更の短い説明をここに入れる"
96 97
```

98
### 9. 最新の Yii コードを upstream からあなたのブランチにプルする
99 100 101 102 103 104

```
git pull upstream master
```

このステップは、プルリクエストを出す前にあなたのブランチが最新のコードを持っていることを確実にするためのものです。
105
もし何かマージ衝突がある場合は、ここでそれを修正してから再度変更をコミットすべきです。
106 107
こうすると、Yii 開発チームがワンクリックであなたの変更をマージすることが確実に出来るようになります。

108
### 10. 衝突をすべて解決したら、あなたのコードを github にプッシュする
109 110 111 112 113 114 115 116

```
git push -u origin 999-name-of-your-branch-goes-here
```

`-u` パラメータによって、あなたのブランチが今後は自動的に github のブランチに対してプッシュおよびプルを行うようになります。
つまり、次回 `git push` とタイプしたときには、git は既にどこにプッシュすればよいか知っている、ということです。

117
### 11. upstream に対して [プルリクエスト](http://help.github.com/send-pull-requests/) を発行する
118 119

github 上のあなたのリポジトリに入って、"Pull Request" をクリックし、右側にあるブランチを選び、コメントボックスにもう少し詳細を記述します。
120
プルリクエストを課題とリンクさせるために、プルコメントのどこかに `#999` という書式で課題番号を記載します。
121

122
> 全てのプルリクエストはそれぞれ一つの課題を解決すべきものであることに注意してください。
123 124 125

### 12. 誰かがあなたのコードをレビューする

126
誰かがあなたのコードをレビューします。あなたは修正を求められるかも知れません。その場合は、ステップ #6 に戻ってください
127 128 129
(現在のプルリクエストが open である限りは、別の新しいプルリクエストをする必要はありません)。
あなたのコードが受け入れられた場合は、コードはメインブランチにマージされて、次回の Yii のリリースの一部となります。
受け入れられなくても、落胆しないでください。
130 131
必要とする機能は人によってさまざまに異なりますし、Yii は全ての人に対して全てを提供することは出来ません。
また、却下された場合でも、あなたのコードはそれを必要とする人々から参照されるように github 上で公開され続けます。
132 133 134 135 136 137 138 139 140 141 142 143 144 145 146

### 13. クリーンアップする

あなたのコードが受け入れられるか却下されるかした後、あなたが作業してきたブランチをローカルレポジトリおよび `origin` から削除することが出来ます。

```
git checkout master
git branch -D 999-name-of-your-branch-goes-here
git push origin --delete 999-name-of-your-branch-goes-here
```

### 注意:

退行 (regression) を早期に発見するために、github 上の Yii コードベースへのマージは、すべて [Travis CI](http://travis-ci.org) に取り上げられて、自動化されたテストにかけられます。
コアチームとしては、このサービスに過大な負担をかけたくないために、
147 148
以下の場合にはマージの説明に [`[ci skip]`](http://about.travis-ci.org/docs/user/how-to-skip-a-build/) が含まれるようにしてください。
すなわち、プルリクエストが、
149 150

* javascript、css または画像ファイルだけに影響する場合
151 152
* ドキュメントを更新する場合
* 固定の文字列だけを修正する (例えば、翻訳をアップデートする) 場合
153 154 155

がそうです。

156
このようにすることによって、そもそもテストによってカバーされない変更に対しては、travis がテストランを開始しないようにすることが出来ます。
157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176

### コマンド概要 (上級の寄稿者向け)

```
git clone git@github.com:YOUR-GITHUB-USERNAME/yii2.git
git remote add upstream git://github.com/yiisoft/yii2.git
```

```
git fetch upstream
git checkout upstream/master
git checkout -b 999-name-of-your-branch-goes-here

/* 魔法を使い、必要なら changelog を更新 */

git add path/to/my/file.php
git commit -m "A brief description of this change which fixes #42 goes here"
git pull upstream master
git push -u origin 999-name-of-your-branch-goes-here
```