「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
Gitのステージング領域の正体を探る | メルカリエンジニアリング
ソフトウェアエンジニアの @DQNEO です。こんにちは。 Gitの内部構造を深掘りするシリーズ３回目です。 前回までのお話はこちら Gitのつくりかた – Mercari Engineering Blog Gitのコミットハッシュ値は何を元にどうやって生成されているのか – Mercari Engineering Blog 今日はみんなだいすき「ステージング領域」の中身について解説してみます。 ステージング領域とは何か？ 簡単に説明すると「次にコミットしたときにコンテンツとして登録されるもの」リストです。(別名「インデックス」ともいいます。) このリストは、 git addやgit rmしたときに書き換わります。 (古くはcacheと呼ばれていました。内部実装やgit diff --cachedに今もその名残があります。) git addのマニュアルに説明があります。 Git – git
[git]マージ時のコンフリクトで片側の変更だけ適用する方法 - Qiita
２つのブランチをマージした際にコンフリクトしたとして、どちらかだけを全面的に適用したい場合はどうするか。 以下のように、checkout --ours と checkout --theirs を使い分ければ良い。 # ２つのブランチ間でコンフリクトしているファイル fileA.txt と fileB.txt があるとする # fileA.txt を現在チェックアウトしているブランチ側の対応に合わせる場合 $ git checkout --ours fileA.txt $ git add fileA.txt # add を忘れずに # fileB.txt をマージさせたブランチ側に合わせる場合 $ git checkout --theirs fileB.txt $ git add fileB.txt $ git commit Register as a new user and use Qi
![[git]マージ時のコンフリクトで片側の変更だけ適用する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2effa206ac1407952bbfa4f3eceeb99dfc08f40c/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCZ2l0JTVEJUUzJTgzJTlFJUUzJTgzJUJDJUUzJTgyJUI4JUU2JTk5JTgyJUUzJTgxJUFFJUUzJTgyJUIzJUUzJTgzJUIzJUUzJTgzJTk1JUUzJTgzJUFBJUUzJTgyJUFGJUUzJTgzJTg4JUUzJTgxJUE3JUU3JTg5JTg3JUU1JTgxJUI0JUUzJTgxJUFFJUU1JUE0JTg5JUU2JTlCJUI0JUUzJTgxJUEwJUUzJTgxJTkxJUU5JTgxJUE5JUU3JTk0JUE4JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yM2E0NWQ1NWY4OGNjMmJkMmY5MGEwOWVjNDk5OTA3Zg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbmFudGVra290YWkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWNiOTkyYjk4YjNkZGQwOWVkMTEzNTAxYTdlZmEyODQy%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D86e5296afa3a927e9fd9ccbe7aa2c1ab)
git log よく使うオプションまとめ - Qiita
git logはオプションがありすぎて全然使いこなせていなかったので よく使いそうなものだけまとめた。 表示形式 git log --oneline --graph --decorateでそこそこ見やすく表示される。 自前のaliasが設定されていない環境でgitを使うときに頭に入れておくとよいかも。 自分は以下のようなaliasを設定している。 [alias] graph = log --graph --date=short --pretty=\"format:%C(yellow)%h %C(cyan)%ad %C(green)%an%Creset%x09%s %C(red)%d%Creset\"
Add some information about properly formatted commit messages · torvalds/subsurface-for-dirk@b659015
WalkMod
... and after running it: public class Calculator { private double total = 0; public int getTotal(){ return total; } public void pow(double value) { total = Math.pow(total, value); } public void sum(double value) { total = total + value; } } From Binary distribution The only requirement is the Java Virtual Machine (equal or greater than 1.7). Download and unzip the to the directory you wish to ins
Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
GitHubでマージ済のプルリクをrevertした後に引き続きrevertされたブランチで作業を続行したい時 - Qiita
GitHub上でプルリクをマージした後に、まだマージできる状態では無かったと気付きrevertする事ってありませんか？ その後に問題になるのが、revertしたのはいいけど、引き続きそのrevertされたブランチで作業してまたプルリクを発行したい。という状況です。 この時に何も考えずに普通に作業を続行してプルリクを発行した場合、revertされた分の変更が失われてしまいます。 結構でかい事故に繋がる場合があるので、この時の対処方法を書きたいと思います。 前提 以下の操作を行っている。 プルリクを発行 プルリクをマージ マージ済のコミットのrevertプルリクを発行 revertプルリクをマージ ここまでの操作はGitHub上ですんなり行える。 再度revertされたブランチのプルリクを発行してみる 普通の感覚だと、また差分が復活していると思うのでプルリクが発行できそうな気分になると思います
GitHub のプルリクエストを fetch しとくと便利 - HWPS別館
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
意外と知らないIntelliJ IDEAのGit管理機能いろいろ（´-`） - Qiita
新卒２年目の大久保です。（´-`） IntelliJ IDEA使い始めて結構経つんですが、未だに機能を活用しきれてないなと感じます。。（´-`） 特にGit周りに関しては知ってると便利な機能いろいろあるので、学習も兼ねていくつかピックアップしてまとめてみました。（´-`） 例で使用しているコードの言語はScalaです。 Annotate機能 現在表示されてるファイルの各行の最終更新日と更新者を確認 ファイルの行番号とかの横にGitのコミット情報を表示できます。 git blameとほぼ同じですね。 ＜やり方＞ 行番号が表示されてるとこを右クリック -> [Annotate]選択 コミットの差分を表示 Annotateによって表示された行を選択することで、そのコミットにおける各ファイルの差分を表示できます。 ＜やり方＞ 行番号が表示されてるとこを右クリック -> [Annotate]選択 -
Git - Git の属性
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
masterブランチでちょっとした変更をしたいんだけど、devブランチで作業しているから切り替えるのはめんどくさい。 そんな時はgit worktreeを使ってみてください。複数のブランチを切り替えずに操作できます。 ※git worktreeを使うにはGit 2.7.0以降が必要です。それ以前のバージョンだとgit worktree listがありません。 ブランチの追加 操作したいブランチはこんな風に持ってくることができます。 すると、作業ディレクトリ以下に指定したブランチの中身がリンクされます。 たとえば、git worktree add ./worktree-dev devとコマンドを打つと、./worktree-devディレクトリが作成され、その下にdevブランチの内容ができるわけです。 git worktreeは今いるブランチに影響を与えません。 つまり、作業中であっても操作し
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
GitHub で submodule ではなく subtree を使うべき理由
GitHub には、タグを打つとソースパッケージを自動的にリリースするという機能があります。スクリプト言語においては、それぞれの言語について一般的なパッケージ管理システム注1があるため、この機能を使うことが少ないかと思いますが、デファクトのパッケージ管理システムが存在しないC等の言語で書かれたプログラムや、単独で動作する管理用のスクリプトを GitHub で開発・配布する際には、本機能はとても便利なものです。 しかし、この機能は git-archive コマンドのラッパーとして実装されているため、サブモジュールのファイルが含まれないという問題を抱えています。この点は GitHub の人たちも認識しているものの、今のところ GitHub で独自に対応するということは考えていないようです注2。 私がこの問題を 知ることになったのは、picojson の issue で指摘を受けたからです。pi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
crocos.jp
Undo a Git merge that hasn't been pushed yet
GitでMerge CommitをRevertする方法 - Qiita
https://qiita.com/falsandtru/items/d81d844afaca8db2756e
コンセプトから理解するGitコマンド
