レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
Writing good commit messages
Good commit messages serve at least three important purposes: To speed up the reviewing process. To help us write a good release note. To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added. Structure your commit message like this: From: https://git-scm.com/book/ch
Git - Contributing to a Project
1. Getting Started 1.1 About Version Control 1.2 A Short History of Git 1.3 What is Git? 1.4 The Command Line 1.5 Installing Git 1.6 First-Time Git Setup 1.7 Getting Help 1.8 Summary 2. Git Basics 2.1 Getting a Git Repository 2.2 Recording Changes to the Repository 2.3 Viewing the Commit History 2.4 Undoing Things 2.5 Working with Remotes 2.6 Tagging 2.7 Git Aliases 2.8 Summary 3. Git Branching 3.
FishEye/Crucible 3.8: performance and patch upload improvements - Atlassian Blogs
An update to customers, stakeholders, and shareholders on our mission to unleash the potential in every team.
@durdn - nicola paolucci
Be Present Now Sometimes witty, sometimes childish. Add gesticulation, shake. Must Have Git Aliases: Advanced Examples Over the course of a few years I piled up a long list of git aliases. This post will assume you know what aliases are and you have defined a few for yourself. I rely on many of them dozens of times a day. And maybe some have slipped your radar. Maybe you’ve never thought you could
とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
工夫と趣向と分別と。git mergetoolでEmacsのediff-merge-files-with-ancestorを呼び出す - 工夫と趣向と分別と。
git mergetoolに使えるツールとして、デフォルトで"emerge"というのが用意されており、Emacs使いはこれを使えばEmergeでマージが行えるわけだが、難点もある。ひとつは、新たなEmacsインスタンスを起動してしまうということだ。起動に無駄な時間が掛かるし、マージにあたって既存のセッションで開いているファイルをその場で参照できないのは不便だろう。もっとも、これはemacsclientを使うようにして、Emergeの呼び出し方を少し直せば済む。もうひとつは、EmergeではなくよりモダンなEdiffを使いたいということだが、これは思ったほど簡単ではないのでわざわざこうして記事を書くことになった。 というのも、Emergeにはemerge-files-with-ancestor-commandという便利なものがあり、「マージが終わったらマージ結果を保存して即終了」ということが
git? tig! | Atlassian Japan 公式ブログ | アトラシアン株式会社
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合： Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
GitLabのPublic AMIを公開しました。 - プログラマでありたい
前回、GitLabのインストール手順をまとめました。しかし、手順はかなり複雑で、たぶん殆どの人がハマると思います。そもそもAWSだから誰かがAMIを作って公開したら良いのはと考えて、試しに自分のAMIをPublicで公開することにしてみました。 このAMIをPublic AMIから検索してください。 ami-b5e270b4 初期設定の仕方 AMI選択後に起動してec2-userでログインしてください。ログイン後にrootになってsetup.shを起動してください。gitlabユーザからgitにsshで接続する為の鍵と、gitoliteの設定を行います。 $ sudo su - # ./setup.sh 後は、Webでログインしてください。ID・パスワードはデフォルトの通りです。 login.........admin@local.host password......5iveL!fe お
Confluence
{"serverDuration": 17, "requestCorrelationId": "f12953c41087422ba55291f4cd3ff3b9"}
天下一gitconfig大会
天下一gitconfig大会(サイボウズ社内git勉強会@2012/11/20)の@teppeisの資料です。 ぎっとぎとにしてやんよ GistDeck gistでmarkdown書いたらbookmarkletでプレゼンになるよ。 ↓これをBookmarkに登録してこのページで実行してみよー！ javascript:(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.setAttribute(%27src%27,%27https://raw.github.com/teppeis/gistdeck/fix/gistdeck.js%27)%3Bdocument.getElementsByTagName(%27head%27)%5B0%5D.appendChild(s)%3B%7D)()%3B 複数行のcodeとかが微
GitをHTTP経由で使うときのパスワードを安全に扱いたい - idesaku blog
Git 1.7.9がリリースされたので、変更点のハイライトをつらつらと眺めてみよう、と思ったら初っぱなに興味深い一文発見。 "Credential helper" support, that allows integration of HTTP authentication with platform-native key-chain implementations; Git Blame: Git 1.7.9 つまり、OS Xユーザからすると、HTTP認証にKeychainを使えるってことではなかろうか。 追記: HomebrewのGitパッケージは2012年4月中旬あたりから /usr/local/bin/git-credential-osxkeychain をインストールするようになっている。 ゆえあって、SSHでなくHTTPSで使用しているGitリポジトリがあるのだが、普通に使ってい
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
プロとしての行為 Act as Proffesional
Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
Checking out pull requests locally - GitHub Docs
GitHub - mirakui/tuningsan
