「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
Githubエコシステムを活用したイマドキの趣味開発 - くりにっき
社内でLTする機会があったので資料を公開します Githubエコシステムを活用したイマドキの趣味開発 from Go Sueyoshi (a.k.a sue445) バックグラウンド 実はこれは先日同僚がRubyKaigi2014で発表した "Gem of this Week" - building culture and making gem のカウンターエントリだったり、補足だったり、そんな感じです。 登壇者のエントリ: RubyKaigi2014で発表した - mitaku.log 残念ながら社内版のcodeclimateやcoverallsに相当するものはないので、業務ロジックや社内のコンテキストが絡まないところに関してはgithubで公開してしまった方がいろいろなエコシステムを活用できると思ってます。 社外に出すとなると 英語でコメント書く issueやPRで英語やり取りが発生す
tigから git rebase -i したらいろいろ捗った - くりにっき
git dtコマンド - razokulover publog を見て自分もgitのコマンドをカスタマイズしてるのを思い出したので普段よく使っているのを紹介します。 対象者 作業途中はtmpコミットをたくさん作って、最後に git rebase -i でコミットを整えている人 前置き gitのタイプ数を減らす gitコマンドを使う時に毎回 git と3文字タイプするのは時間の無駄なのでエイリアスつけるのをおすすめします ~/.bash_profile とか ~/.bashrc 辺りに下記を書きます。 alias g='git' これで g だけでgitコマンドが使えます git-now iwata/git-now tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ 最速でtmpコミットするためのコマンド。Macなら brew install git-
初心者向けWIPワークフロー&レビュー時の注意 - Qiita
# masterブランチに移動 git checkout master # masterブランチを最新にする git pull origin master # 新しい作業ブランチを作成 git checkout -b new_branch # 空コミットを作る git commit --allow-empty -m "[WIP] 今回開発する内容を書く" # push git push origin new_branch この後、Githubの画面に行ってpull requestを送ります。 2.タスクを洗い出す Githubのプルリクエストにタスクを積みましょう。 下記のようにコメントすればチェックリストが作れます。
gitで新しくブランチを切るベストプラクティス - 時計を壊せ
普段から普通にやっている方法です。 git fetch git checkout -b $BRANCH_NAME origin/master git push -u origin $BRANCH_NAMEgit fetchでoriginを最新にして、origin/masterからブランチを切ります。 これで、プロジェクトの最新の状態からbranchを切る事が出来ます。 現在どのbranchに居るかを気にせずとも、branchを切る元を間違える事がないので安心です。 （例えばうっかり関係ないtopic branchから切ってしまう。といったことを気にしなくて良くなります。） また、git push -u origin $BRANCH_NAMEすることにより、 リモートブランチがupstreamとして紐付く為、いちいちgit pull origin $BRANCH_NAMEとかしなくて良くなり
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/ta9to/items/fc099e5153c22590a970