pyar.bz

Github-flowを分かりやすく図解してみた

Category: 開発手法
Tag: git, github, github-flow, チーム, 図解

「github チーム 使い方」とかでggってみたら、git-flowとGithub-flowがごっちゃになっててわかりづらい。他の人に説明する時にも使いそうなので、個人的にまとめてみた。

Contents

Github flowって何よ?

複数人で開発するときに、github上のリポジトリをどう運用するかをまとめたもの。

概要教えて

  • masterブランチのものは、いつでもデプロイ出来る状態で無ければならない
  • 新しい何かに取り組む際は、masterからブランチを作成する
  • 作成したブランチは、説明的な名前を付ける(例: new-oauth2-scopes)
  • 作成したブランチは、定期的にgithub上へgit pushする
  • フィードバックや助言、ブランチのマージをして欲しいときは、github上でpull requestを作成する
  • 他の誰かがレビューをする。
  • OKが出たら、masterへmargeできる
  • マージをしてmasterへpushしたら、直ちにデプロイをする

特徴は?

  • リポジトリは1つだけを共有する (forkしない)
  • 開発する人をColleboratorに登録し、登録されていない人はgit pushできない
  • ブランチでタスク (今やってること) を管理できるので、運用が楽。

欠点は?

  • 集中型管理であるため、非匿名多数での開発には向いていない。(例: オープンソースプロジェクト)
  • teamリポジトリでない場合、masterブランチにgit pushする恐れがある。
  • リポジトリが1つしかないので、アカウントが消えたら色々死ぬ。(ローカルにデータがあれば別)

流れを図で説明して

こんな流れになる。

実際にどうやんの?

1.リポジトリを準備する

レポジトリを作成する

README.mdを作成するにチェックを入れて、レポジトリを作る

2.各ユーザーをCollaboratorに登録する

Collaboratorに登録する。登録者以外はgit push出来ないようにする。

3.git clone

github上で作成したリポジトリをローカルに持ってくる

1
2
$ git clone "your_repository"
$ cd "your_repository"

4.masterからgit branch

機能毎にブランチを切る。ブランチ名は説明的な名前。

1
$ git checkout -b "new_branch"

もしくは

1
2
$ git branch "new_branch"
$ git checkout "new_branch"

5.コーディング

コーディングする。

6.git push

ローカル上で切ったbranchを定期的にgithubに反映させる

1
2
3
$ git add -A
$ git commit -m "commit messages"
$ git push origin "new_branch"

7.pull request

もし、以下のことをしたい場合、github上でpull requestを送る

  • レビューしてほしい
  • ここが分からない
  • 完成したのでmergeしてほしい

8.masterブランチへmarge

github上で許可が出たら、github上でmergeする

9.直ちにdeploy

deployして反映させる

10.ブランチを削除

機能更新が終了したら、ローカル上でブランチを削除する

1
2
$ git checkout master
$ git branch -D "new_branch"

github上のブランチを削除する

1
$ git push origin :"new_branch"

11.git pull

git pullしてmasterリポジトリを更新する

1
$ git pull origin master

もしくは

1
2
$ git fetch origin master
$ git marge origin/master

あとは4~11を繰り返すだけ

参照

https://gist.github.com/Gab-km/3705015

Tag Cloud

Comments