git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
Choose GitLab for your next open source project | agilob in the Net
agilob in the Net hacking, programming, java, c++, privacy, firefox Menu Skip to content cd $HOME English Cryptocurrency Linux Privacy Programming Polski Hacking Linuks Osobiste Programowanie Prywatność Studia w UK Contact GitLab.com is a competitor of GIthub. It’s a service provider for git-based source code repositories that offers much more than it’s bigger brother. In this post I will try to c
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
gitに新機能を追加してgit masterを目指す(初級編) - クフでダローバルな日記
学科の実験「大規模ソフトウェアを手探る」でgitを弄って改良しようとしたので、その過程と結果を何回かにわたって書いてみようと思います。 「レポートとしてブログ記事が認められる」という変則的な実験なので、レポートとして書きますが、文体は敬語かつ口語っぽく書かせていただきます。 また、単にハウツーを書くだけではなく、チームや個人としての感想や想いについても書かせていただきます。 というのも、ブログ記事が推奨されている理由が、 今後同じく大規模ソフトウェアやOSS、特に自分の暑かったソフトについて手探ろうとしている人たちの参考となるため であるためです。 従って、この記事は単なるレポートではなく、他の方に参考にして戴ける記事にしたいと思っているので、質問や意見などがあればコメント欄やはてブコメントなどで仰ってください。 twitterは@showmeearなので、リプを飛ばしていただいても構いま
A useful template for commit messages — David Winterbottom
Here’s a useful heuristic for writing better commit messages. Set your commit message template to: # If applied, this commit will... # Why is this change needed? Prior to this change, # How does it address the issue? This change # Provide links to any relevant tickets, articles or other resources and you’ll be guided into writing concise commit subjects in the imperative mood — a good practice. Se
How To Deploy a Rails App with Git Hooks on Ubuntu 14.04 | DigitalOcean
// Tutorial //How To Deploy a Rails App with Git Hooks on Ubuntu 14.04 Introduction In this tutorial, we will show you how to use Git hooks to automate the deployment of the production environment of your Rails application to a remote Ubuntu 14.04 server. Using Git hooks will allow you to deploy your application by simply pushing your changes to a production server, instead of having to manually p
git/コミットログを修正する方法 - TOBY SOFT wiki
はじめに † gitでコミットログを修正したいです。 Redmineとかで、refs #10とかcloses #10とかつけるとコミットログにチケットを関連付けられますが、これがよく書き忘れるんですね…。 直前のコミットログを修正する方法あるみたいです。 直前のコミットログ以外も修正する方法はないのかな…。 (Subversionだとhookスクリプトで許可できますよね。分散型だとやっぱり無理？) ↑ 直前のコミットログを修正する方法 † 直前のコミットログの修正は"git commit --amend" でよいみたいです。 例えば、 $ git commit -m "fixed xxx bug" : # コミット完了! # あ！しまった！"refs #(チケット番号)"つけるの忘れてた！ # (私が使うプロジェクト管理ツールRedmineではrefs #13 のようにすると # コミット
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 から入って
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
【git】 コミットをせずにインデックスにあるファイルを一時退避させる git stash - 旅するえんじにあ - Engineers to Travel -
今の仕事ではルール上いろんなブランチを行き来しながら作業することが多いです。 そんな時よく発生するのが、作業中に急に別ブランチで作業しないといけないみたいな。 しかも作業中で今commitしたくない・・・ そんな時にはgit stashを使います。 まずは新規ファイルを作ってみる $ touch foo.txt $ git status # On branch test_stash # Untracked files: # (use "git add ..." to include in what will be committed) # # foo.txt nothing added to commit but untracked files present (use "git add" to track) ファイルをaddしてインデックスに追加する $ git add . $ git
git rebaseって超便利じゃね？ - Seasons.NET
Gitでとても便利だと思っているのが、rebaseというコマンド。 ブランチを切った時点からオリジナルは刻一刻と変化していくわけで、 自分のブランチはあくまで現在最新のオリジナルに対するパッチである 必要がある場合は、このrebaseというコマンドを使って、オリジナル(HEAD)と マージすると、最新のオリジナル(HEAD)に対して、ブランチを切ったことになります。 これチョー便利じゃね？ 以下、git-rebaseから引用 git-rebase を使用して一連のパッチを最新に保つ リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、幾つかコミットを作成したとします： $ git checkout -b mywork origin $ vi file.txt $ git commit $ vi otherfile.txt $ git commit ... m
How to undo (almost) anything with Git
Open SourceProductHow to undo (almost) anything with GitOne of the most useful features of any version control system is the ability to "undo" your mistakes. In Git, "undo" can mean many slightly different things. One of the most useful features of any version control system is the ability to “undo” your mistakes. In Git, “undo” can mean many slightly different things. When you make a new commit,
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
How to write the perfect pull request
EngineeringHow to write the perfect pull requestAs a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we've found it useful to remind ourselves what we aim for when… As a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we’ve found it useful to remind ourselves what we aim for when we communicate. We re
VimプラグインのGit界隈について - Qiita
前書き 以前、VimでGit連携といえば、fugitiveが定番で(参考1、参考2)で、コミットツリーの確認するにはGitvが便利、という状況でしたが、最近、次々と新しいプラグインがリリースされていますので、紹介したいと思います。 Agit.vim git log を見やすく表示するためのプラグインです。 従来より、gitv というプラグインがありましたが、それら機能に加えて、修正されたファイル一覧も見られるようになっています。 また、gitvにあった以下のような難点も改善されています。 キーバインドをカスタマイズするために、filetype=gitvのautocmdを作成しなければならない 外部コマンド(git)の実行タイミングの影響かなんかもっさり encodingの設定によっては日本語のコミットログをデコードに失敗して文字化けする 参考: gitk クローンみたいな Vim プラグイ
コードレビューさせないようにコミット - Qiita
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットしても、後できれいにコミッ
SourceTreeとGitではじめるバージョン管理 #1 - あおたくノート
以前、創作活動をしている人のためのバージョン管理入門 という記事を書いた。導入だけやってまだ踏み込んだ使い方の記事書いてないなーと思って続き書こうとしたんだけど、最近SourceTreeというバージョン管理クライアントを使ってみたらめっちゃ使い勝手が良かったのでそれの紹介します。 バージョン管理システムって？ファイルの変更履歴を記録して、後から読み返したり、履歴間の差分を出したりするためのシステムのこと。 SubVersionGitMercurialとかがある。 個人で使うならGitやMercurialが便利。 今回はGitを使う。 Windows 7以降でGitを使うならSourceTreeがおすすめ。メニューは英語表示で日本語化されてないけど、使い方を一度覚えてしまえば大丈夫。 SourceTree ダウンロードして、インストールする。 Windows XPなんだけど……GitHub
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.yoslab.com/entry/2013/12/26/184615
gitの個人的虎の巻
GitHub - k88hudson/git-flight-rules: Flight rules for git
