GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
フェッチ機能を活用してプルリクエストに習熟しよう！ | Atlassian Japan 公式ブログ | アトラシアン株式会社
最近では、プロジェクトの修正もフォークの作成同様、簡単になりました。フォークを作成する際に作業するプロジェクトの完全な遠隔コピーをあっという間に作れるように、変更したいファイルを選択し、編集するを押して修正をコミットする事で、プロジェクト修正が行えます。 仮に、自分がプルリクエスト (以下、PR と表記) の受け取り側である場合はどうなるのでしょうか？優れた Web UI があれば助かりますし、多くの場合はそれで済みます。ボタン操作 1 つで承認、マージ、どちらも完了します。 しかし、常にそうはいきません！プルリクエスト (PR) に含まれている変更点をローカルでダウンロードして、テストをいくつか実行し、起きた内容を把握するために自身の IDE における見え方を確認しなくてはならない事もよくあります。 同僚あるいはコントリビューターのプルリクエストをダウンロードする際のステップ、即ち fe
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
GitHubのPull Requestを簡単にチェックアウトするたった1つの方法 - アジャイルSEの憂鬱
みんな知ってるものだと思ったけど、あまり周りで知ってる人がいなかったのでブログに書いた。 こういう釣りタイトルっぽいブログ、一度書いてみたかった。 参考 Checking out pull requests locally - User Documentation 参考というか、そのままだけど。 方法 Pull Requestの ID を BRANCHNAME にfetchします。 *1 $ git fetch origin pull/ID/head:BRANCHNAME ブランチをcheckoutします。 git checkout BRANCHNAME これだけです。forkした人のリポジトリを remote add する必要はないです。 おまけ マージ後のsha1 ちなみに、Pull Requestのマージ前だと、 pull/ID/merge を使うこともできます。 $ git fet
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
署名付きタグって何？ - idesaku blog
Gitを使い始めて以来、ずっと飲み込めずに残っているのが、"署名付きタグ"という代物である。これ、どういうときに使うのだろうか？ あちらこちらのドキュメントを見ても、「署名もできて嬉しいね」としか書いていない。つまり、それが有益であることはたぶん一般的に自明のことなのである。が、恥ずかしながら俺はよくわからない。 よくよく考えて、なんとなく理解できたと思うので、メモしておきたい。 三種類のタグ Gitでは、三種類のタグを作成できる。 軽量タグ 注釈付きタグ 署名付きタグ "軽量タグ"は、CVSのタグのようなものである。特定のコミットにマークをつけるが、それだけ。 $ git tag v1.0"注釈付きタグ"は、Subversionのタグのようなものである。タグをオブジェクトとして登録し、そこにコメントを含められる。 $ git tag -a v1.0 -m "バージョン1.0リリース。""
Merging without whitespace conflicts
I've got a problem, where a large commit which changes about a thousand lines of code, removing whitespace from the end of lines and removing spaces before tabs. There are also about 50 pull requests for this project, in which all will get conflicts, when my commit is merged. Is there any way that git can be set up so that when merging future commits, it ignores conflicts where one of them is just
Ruby - [翻訳] 私のコミットをまとめないで - Qiita
はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. （許可は取りましたヨ） Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立してるいるはずだからまとめる必要はない 仮にどうしてもまとめたいなら自分でやるべきだし人にその考え方を押し付けるな (まあ実際は皆いい人だから理解してくれるけど） この方は徹底してcommitを最小の変更単位で分けて、 それぞれが独立してテストを通るように心が
![Ruby - [翻訳] 私のコミットをまとめないで - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/a629bd4886a52844b130b2c1e8e8446b5163ab5b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwJUU3JUE3JTgxJUUzJTgxJUFFJUUzJTgyJUIzJUUzJTgzJTlGJUUzJTgzJTgzJUUzJTgzJTg4JUUzJTgyJTkyJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgxJUE3JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MDI1MWZhNTYyZWZlMjcwYjFkOGUzZDUzZjExYTkzNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwZ29nb3RhbmFrYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NjRiZDU0YWRmMDJhMWI2NmFhYzE4OTBlOThkNDY5MWM%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Daf6fea5511a5df3f46a1b9fb611654d8)
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
その後の俺のオレオレgit-flow〜deployment手法とgit運用 | おそらくはそれさえも平凡な日々
http://togetter.com/li/673629 こういうふうにまとめてくださっていたのですが、自分なりの考えの補足など。 上記でも言及している、「俺のオレオレgit-flow」というエントリにも書きましたが、この運用で進めてみて結構良かったなーと思っている。その辺に関しては以下のツイートしたりした。 masterでQA通してからreleaseブランチにマージしてdeployって感じすなー。 — songmu (@songmu) 2014, 5月 30 ゲームだと画像内の文字の表記間違いとかをやらかすだけで、その事後対応でプログラマの稼働が下手すりゃ一日飛ぶので、master直deployは怖いので、並列でreleaseブランチを走らせて、そっちにマージしつつdeployしてる。 — songmu (@songmu) 2014, 5月 30 masterからreleaseへのマー
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
GitHub Flow (Japanese translation) Latest version is here: https://gist.github.com/Gab-km/3705015
GitHub Flow Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップでgit-flowについてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
SourceTree で force push - 尋常でないもふもふ
SourceTree でフォースプッシュできないことだけ不便だなーと思ってたけど、Mac 版ではいつのまにか実装されてた件。 リリース日は 2013年9月18日 SourceTree for Mac 1.7 – Now Available! ・Force push supported as a checkbox if enabled from preferences 設定 デフォルトでは無効になってるので、環境設定＞全般の最下部付近の項目にチェックをいれる。 upstream に force push するのは暴挙なので、UI 的に正しいと思う。force push は自分専用のリポジトリ（フォークしたリポジトリ含む）に対してだけ行うべき。 プッシュのとき そうするとプッシュのタイミングでチェックボックスが現れる。 翻訳が変だけど。 （追記1） 2014-10-07 にリリースされた So
The Tig Manual
This is the manual for Tig, the ncurses-based text-mode interface for git. Tig allows you to browse changes in a Git repository and can additionally act as a pager for output of various Git commands. When used as a pager, it will display input from stdin and colorize it. When browsing repositories, Tig uses the underlying Git commands to present the user with various views, such as summarized comm
Gitレポジトリを移行する方法 - Qiita
既存のGitレポジトリを、GithubやBitBucketのようなホスティングサーバに移行したり、逆にローカルサーバのGitBucketやGitLabなどに移行したい場合、（乗り換えなど）まあ単純にpushすればいいやんと思ったら、思うような結果にならなかったり、面倒な手順になってしまったりしてしまった。 どうも自分のワーキングのレポジトリから飛ばそうとすると、tagだったりbranchだったりが移行できていないかったりするのです。 ぐぐると、いったんローカルにリモートと同名のブランチ作って(checkoutして)から、push --all, --tags とかしてる奴とかありますがそれは面倒だなぁやだなぁみたいな。 最終的には、これが一番楽な手順かなと思う手順に行きつけたのでここに記す。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd
データのためのGit（およびGithub） | オープンデータとオープンガバメントを推進する Open Knowledge Japan
（訳注：この記事は本家OKFn.org記事の日本語訳です） データのために「バージョン管理」を行う能力は重要な関心事です。様々な選択肢がありますが、最も魅力的なもののひとつは、Git やMercurial のように、コード用の既存ツールを再利用することです。この投稿では、私たちが暫くの間使用してとても効果的だということが分かったツールを利用する、データの格納とバージョン管理のための単純な「データ・パターン」について記述しています。 序章 行われた変更を格納し、それを他の人と共有する、データのバージョンとリビジョンを管理する能力、とりわけ分散的な手法は（オープン）データ・コミュニティにとって大きな便益となるでしょう。私はその理由を以前（こちらの初期の記事を参照）議論しましたが要約すると： 効率的な分散型の共同作業が可能です。私のデータセットを取り出し、変更し、それを再び私と（同時に他の人とも
Gitでリモートのマージ済みのブランチを一括削除する - by shigemk2
Gitでリモートのマージ済みのブランチを一括削除する - Qiita [キータ] こいつは便利だぜ。 $ git branch -a --merged | grep -v master | grep remotes/origin| sed -e 's% *remotes/origin/%%' | xargs -I% git push origin :%$ git branch -a --merged | # リモート ローカル問わずmergeされたブランチを grep -v master | # masterブランチを除き grep remotes/origin | # remotes/origin ブランチのみを取りだし sed -e 's% *remotes/origin/%%' | # 'remotes/origin'文字列を削除して xargs -I% git push origi
Pro Gitと入門Gitと入門gitでGitの復習 HEADのキャレットとかチルダとか補講編 - kk_Atakaの日記
前回までのあらすじ Pro Gitと入門gitでGitの復習 基本操作編 - kk_Atakaの日記 Pro Gitと入門gitでGitの復習 ブランチ編 - kk_Atakaの日記 Pro Gitと入門gitでGitの復習 マージ編 - kk_Atakaの日記 GitHubで他の人の.gitconfigとかを見たりすると、HEAD^とかHEAD~~とかにエイリアスが貼ってあるけど、これってなんなの？ 今の認識: 書いた分だけリビジョンが戻ってくれる程度 参考 Git - Book 入門Git New !! 入門git 調査 入門Git P87 コミットの祖先の指定によると、 記法 意味 ^ 指定したコミットの1番目の親 ^番号 指定したコミットのN番目の親 ~ 指定したコミットの1世代前の親 ~世代 指定したコミットのN世代前の親 という事らしい……が、番目と世代は何が違うんだろう？ と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Maintain a Git repository | Bitbucket Cloud | Atlassian Support