Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi
GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’
git commit時のコメントを英語で書くための最初の一歩 | hiro345
最近、開発環境のテンプレート構築をしているのですが、「git commit するまえに考えるべき10のこと | Act as Professional – hiroki.jp by HIROCASTER」みたいに、ソースコードのバージョン管理を実際に始めるときに理解しておかないといけないことは、結構あるはずです。 それで、ソースコードのバージョン管理については、git commitするときに記録するコメントについて、いろいろと考えることもあります。Git Styleは「git/Documentation/SubmittingPatches at master · gitster/git · GitHub」にありますから、こういうのも参考になります。 英語で記述 一文の場合、文末にピリオドを付けない 主語は省く 時制は現在形 文頭の英単語は大文字 他にもないかなぁ、と探してみたら「Chang
LGTMでめでたさを伝えるChrome拡張をつくった
先日、高速にドッグフードを食べる方法を見て、LGTMとLGTM.inというサービスを知りました。 LGTMは、“looks good to me."の略で、GitHubのプルリクに対するOKコメント、LGTM.inは、そのコメントにノリのいい画像を添えてspice upしようというサービスです。コードレビューの終わりにめでたさを伝えてもらえれば、字面だけのLGTMよりもうれしいし、そういう小さな承認はお互いに大事。 ということで、LGTMでめでたさを伝えるChrome拡張をつくりました。 LGTM Chrome拡張 インストールはこちらから。 Chrome ウェブストア/LGTM 拡張を起動するとLGTM.inから取得したランダム画像を3件表示します。 画像が気に入らないときはMore LGTMボタンをクリックして画像を再取得できます。 使い方 使用したいLGTMの画像をクリックするとUR
Contact GitHub - GitHub
Where future developers meet GitHub Global Campus helps students, teachers, and schools access the tools and events they need to shape the next generation of software development. Join Global Campus Student Developer Pack Get the best developer tools There’s no substitute for hands-on experience, but for most students, real-world tools can be cost prohibitive. That’s why we created the Pack with s
github-git-cheat-sheet-V1.1.1-ja.2 copy
変更の作成 変更をレビューしコミット操作ログを作成します $ git status コミット可能なすべての新規または変更のあるファイルを一覧で表示します $ git add [file] バージョン管理のためにファイルのスナップショットを作成します $ git reset [file] ファイルをステージングから外しますが、その内容は保持します $ git diff まだステージされていないファイルの差分を表示します $ git diff --staged ステージングと最後のファイルバージョンとの差分を表示します $ git commit -m "[descriptive message]" ファイルのスナップショットをバージョン履歴内に恒久的に記録します ツールの設定 すべてのローカルリポジトリ用の、ユーザー情報設定方法 $ git config --global user.name
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Git初心者のための資料まとめ
Gitを使ったことがない人が、Gitを最初に取り入れるときにぜひ読んでほしい資料をまとめてみました。初心者のWebエンジニアが、clone, checkout, add, commit, pushやPull Request(Pull Request)ができるようになるまでの一連の流れができるようになることを目標にしています。 (09/06 17:45) はじめてコードレビューされる人のためのPull Requestとcommitの作り方を追加 🐹 目標Git コマンドのclone, checkout, add, commit, pushを使えるようになること プルリクエストができるようになること 🎃 基本的な概念の理解イラストでわかる！git入門の入門 (1) ソフトウェア開発におけるバージョン管理の考え方、(2) Gitを使った開発の基本的な概念、 (3) 基本的なコマンド(add,
Git-doc-ja_JP
これは Git ドキュメントの翻訳作業用プロジェクトです。 リポジトリは https://github.com/ktateish/git-doc-ja_JP にあり、 ja_JP.work: 作業用ブランチ master: 翻訳済みブランチ となっています。誤訳等あれば ja_JP.work に対するPRなどでご指摘ください。 原文と訳を比較する場合、 ja_JP.work ブランチのファイルが原文と訳の両方を 含んでいるので比較が楽です。 最終的には https://github.com/yasuaki/git-doc-ja/ にマージしていけたらと思います。 翻訳済みドキュメントは以下の通りです git-add git-branch git-checkout gitworkflows Copyright, ライセンスは原文(Git本体)と同一です。
「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきました #githubjp - 若くない何かの悩み
「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきました！Gitの中・上級者向けの素晴らしい勉強会でした。おもしろかった！ 今回の勉強会で一番面白かったのは、「とりあえずコミットをしろ。そうすりゃあとでなんとでもなる」です。git reset --hard によって消えたはずのコミットが git reflog から復元できるなんて目から鱗でした。現在の変更を破棄したい場合でもとりあえずコミットしておけ、という教訓の意味がやっと分かりました。 末尾に勉強会のノートを添えておきます。 このイベントは、その場で図を書くような説明などアドリブが多く、とてもわかりやすかったのですが、まとまった資料を貼るのが難しそうな発表でした。したがって、資料は公開されないかもしれません。とすると、このノートはいまのところ唯一の資料です！ ちなみに、会場の様子はこんな感じでした。勉強会の後の
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
Git入門 v1.1.0
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
ぐにゅぐにゅ動く直感的なGitクライアント ungit｜TechRacho by BPS株式会社
ungitはnode.jsで動くグラフィカルなgitクライアントです Learn Git Branchingみたいな直感的なGUIで操作できるので とても分かりやすいです インストール 今回はnvmを使用してnode.jsを入れます $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm install v0.10.22 $ npm install -g ungit $ nvm use v0.10.22 ログイン時も有効にしたい場合は.bashrcに以下のように書いておきます if [ -d $HOME/.nvm/ ] then source ~/.nvm/nvm.sh nvm use v0.10.22 > /dev/null fi 起動 以下のコマンドで
Git Cheatsheet
stash workspace index local repository upstream repository status Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the workspace and the index file, and paths in the workspace that are not tracked by git. diff Displays the differences not added to the index. diff commit or branch View the changes you have in your workspace
操作体系から見る、GitとMercurialの8つの違い
つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
Gitを使いこなすための20のコマンド | OSDN Magazine
LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 なお、Gitの基本的な考え方や使い方については分散バージョン管理システムGit入門でも紹介しているので、そちらも参照してほしい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入門書には載ってない Git & GitHub Tips
こわくないプルリク
gitignore.io - Create useful .gitignore files for your project
