Skip to content

Instantly share code, notes, and snippets.

@ukiuni
Forked from Gab-km/github-flow.ja.md
Last active June 3, 2016 23:39
Show Gist options
  • Save ukiuni/71a4039d11bad7234c95 to your computer and use it in GitHub Desktop.
Save ukiuni/71a4039d11bad7234c95 to your computer and use it in GitHub Desktop.
GitHub Flow (Japanese translation)

GitHub Flow

31 Aug 2011

git-flowの問題点 (Issues with git-flow)

私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップでgit-flowについてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム(Git)を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。

しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見を聞く。

私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大なヘルパースクリプトであり、あまりに複雑すぎる。

クールかもしれないが、GitのGUIツールには強制できず、コマンドラインでしか使えないという問題がある。すべての手順を手動で行う必要があり、そのための複雑なワークフローをしっかりと学ばなければならない人たちというのは、コマンドラインでの作業に不慣れな人たちとイコールでもある。これは大きな問題点だ。

これらの問題点は、手順をもっとシンプルにするだけで容易に解決できる。GitHubでは、git-flowを使っていない。私たちが使う手順、いつも使っている手順はとてもシンプルなGitワークフローだ。

そのシンプルさには多くのメリットがある。ひとつは、簡単に理解できるということ。より素早く作業ができ、何かを台無しにしてしまうとか間違ってしまった手順をやり直すといったこともめったに起こらない。他にも、プロセスを支援するためのラッパースクリプトが必要ないため、GUIプログラムも問題なく使えるというメリットもある。

GitHub Flow

How We Do It

#1 - ANYTHING IN THE MASTER BRANCH IS DEPLOYABLE

#2 - CREATE DESCRIPTIVE BRANCHES OFF OF MASTER

#3 - PUSH TO NAMED BRANCHES CONSTANTLY

#4 - OPEN A PULL REQUEST AT ANY TIME

#5 - MERGE ONLY AFTER PULL REQUEST REVIEW

#6 - DEPLOY IMMEDIATELY AFTER REVIEW

Conclusion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment