Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと コードレビューさせない レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットし
この記事はGit Advent Calendar 2014の6日目の記事です! (更新がお昼になってしまいました、ごめんなさい><) みなさん! Gitの-pオプション使ってますか? 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します! 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね! 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
コードレビューしてますか? 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか?といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. (許可は取りましたヨ) Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立し
先日発売した「Web製作者のためのGithubの教科書」をkwappaさんからご恵贈頂きました。ありがとうございます! Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール 作者: 塩谷啓,紫竹佑騎,原一成,平木聡出版社/メーカー: インプレス発売日: 2014/10/24メディア: 単行本(ソフトカバー)この商品を含むブログ (2件) を見る 著者は塩谷さん(kwappaさん)のほか、サイバーエージェントの紫竹さん、原さん、平木さんというそうそうたる面々。どう考えても間違いないでしょー!というわけで書評を書かせて頂きます。 どんな内容? 本書は「Web製作者のための〜」シリーズのGitHub本で、タイトルからも分かるとおり「Web製作の現場」をターゲットとしています。今までエンジニア以外の方を対象としたGit本はなかったと思うので、待ち望んでいた方もたくさんい
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
経営本部部門に異動して開発環境の整備に専念 アプリケーションやサービスの開発、あるいはWebサイトの制作などにおいて、欠かせないツールとなっているのがバージョン管理システムです。とくに多人数で開発を行う際、いつ誰がどのファイルを編集したのかをすばやく把握できる、あるいはファイルに加えた変更履歴を簡単に参照できるといったメリットを持つバージョン管理システムは、プロジェクトを円滑に進めるうえで極めて有用です。 サイバーエージェントのアメーバ事業では、このバージョン管理システムとしてApache Subversion(SVN)をメインで使っていましたが、エンジニアの間から「Git」を使いたいという声が高まり、それに応える形で「GitHub Enterprise」を導入、2013年4月から本格的に運用を開始しています。この導入プロジェクトを主導した奥田順子氏は、そもそものきっかけを次のように説明し
モダンなチーム開発環境 モダンなチーム開発環境の考慮ポイントの図解 ソフトウェア開発は、ビジネス価値を創造する一翼を担っていますので、ビジネスアイデアをビジネス価値に転換するビジネスパーソンの意向は、とても大切です。それを「動くソフトウェア」にするために、開発エンジニアリングを行うわけですが、それがとても複雑であるということです。ウォーターフォールモデルで開発できる場合は、工程ごとにガッツリ全体を作っていくのである意味シンプルに見えます。しかし、それらの成果の関連や追跡可能性を考えてみるとウォーターフォールモデルで追跡可能性を創出し、維持することはとても難しいことはわかってきます。では、アジャイルな開発、優先順位を決めて、提供可能なものを選んで開発し、提供し続けるモデルの場合は、企画ー計画ー開発ービルドーデプロイが何度も繰り返されるだけではなく、パラレルに動くことが要求されます。たとえば、
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
背景 oh-my-zshは大変便利で、便利ではあるけど複雑怪奇なzshの設定を簡単に済ませることができるようになりました。 しかし、気の赴くままにpluginを追加していると、起動が重くなったり補完が重くなったり徐々に使いづらくなってしまいます。初回の起動が重いのはscreenやtmuxを活用してつぎつぎzshを起動・終了している人にはじわじわ効いてきますし、補完が重いのはとてもつらいものです。 また、oh-my-zshのpluginには、元のrepositoryからsourceを持ってきたまま放置されているものもあります。例えば、oh-my-zsh/plugins/zは2014-04-11時点では本家のrupa/zより古く、更新されてないことが伺えます。 oh-my-zshはいろいろつらさもあることは分かった、しかしoh-my-zshを捨てて一からzshを設定するのはつらい……。そんな方
Prezto 今回はコマンドライン環境の話です。私は以前より oh-my-zsh を利用していましたが、テーマの調子が悪かったので Prezto に乗り換えてみました。結構快適だったので、いまは Prezto を使っています。 本稿では Zsh + Prezto で快適なコマンドライン環境を構築する方法について簡単ですがご紹介します。 Zsh + Prezto 環境を構築する 環境構築の手順については README に書いてありますので、手順通り進めれば問題なく環境づくりができると思います。なお、コマンド実行すると .zlogin .zlogout .zprofile .zshenv .zshrc のシンボリックリンクを貼るので、oh-my-zsh から乗り換える場合など、既存の Zsh 環境を引き継ぎたい場合は各設定ファイルを退避させておきましょう。 // Zsh起動 $ zsh //
いやー今年もISUCONの予選参加募集がはじまりましたね! 昨年は出題側だったので胃が痛かったですが、今年は参加側ですので大変楽しみにしております。@acidlemonです。 Docker使ってますか? さてみなさん、Docker使ってますか? 使ってる? 使ってない? ぼくは使ってませんでした。えー今どきBlue-Green Deploymentやってないの? Immutable Infrastuctureじゃないの? と言われそうですが、世の中にはいろんなしがらみとかもあってなかなか簡単にエイヤーでコンテナに移行できるわけでもないのは皆さんなんとなく感じているのではないでしょうか。 とはいえ、最近これだけ話題になっているDockerですので、そろそろ使ってみたいなぁ…ということで、まずは開発環境をDockerで上げられるようにしました。 Dockerでコンテナを作るときには2つのアプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く