GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
GitHubのREADMEをサクッと高品質で書けるサービス作ってみました。 - Qiita
みなさんは GitHub でオープソースソフトウェア(OSS)を開発して公開する時、README をどのように書いているでしょうか？ GitHub が自動で作ってくれる README に含まれるのはタイトルだけですし、OSS 開発初心者の場合、そもそも README に何を含めるべきかわからないという方もいらっしゃるのではないでしょうか？OSS 開発に慣れている方でも、コードを書くのはいいけれど README を書くのは面倒だと思ったことはありませんか？今回はそんな README 難民の方々向けの Web サービスを作ってみました。 LEADYOU - README Generator Web サイトへ 使い方 使い方は簡単です。トップページで GitHub の Public リポジトリの URL を入力してNext Stepボタンを押すと、README に書くべき内容ごとにフィールドが設
GitHub Flow 図解 - Qiita
概要 Git・GitHubを利用したシンプルで強力なワークフローであるGitHub Flowを図にまとめました。 GitLabでも利用可能なFlowです。GitLabの場合は Pull Request を Merge Request に読み替えてください。 前提 実際にGitHub Flowを実践したことはありません。（2014/06/12時点） これからチームで導入予定で、メンバーとワークフローを共有するために図を作成しました。 ワークフローの誤りなどご指摘いただけると幸いです。 アクティビティ図をベースに作成してありますが、厳密な記法よりも 相手に伝わればいいかな、という点を重視しています。 基本原則 masterブランチは 常時デプロイ可能 である 機能追加、バグフィックスなどは 説明的な名前のブランチ をmasterから作成する 機能追加の例： add_user_notice (ユ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitプロトコルが使えない環境での、たった一つの重要な設定 - Qiita
