ソースコード管理ツールをSubversionからGitへ変更して感じたこと - torutkのブログ
少人数チームでのソフトウェア開発でソースコードを管理するリポジトリにGitを適用して1,2ヶ月ほど経過しました。Gitを開発に使用するのは今回が始めてで、みなSubversionを使っていたメンバーです。 開発環境 OS Linux、たまにWindows 開発言語 Java プログラミングツール NetBeans 7.4 Gitクライアント NetBeans標準搭載のGit機能、たまにコマンドライン、WindowsではたまにTortoiseGit Gitサーバー apacheでgit-http-backend、Redmineと認証統合 現在の使用状況 Gitの共有リポジトリを、開発サーバー上にapache（HTTP）でホストしています。 共有リポジトリはmasterブランチ一本で、各メンバーはローカルにcloneしたあとローカルのmasterで変更作業を実施し、適宜共有リポジトリのmast
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 による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
イケててヤバいGit入門 | GREE Engineering
この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか？私はダメです。ごめんなさい。（´・ω・｀） WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitやGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基本的にA successful Git branching model（有志の方による日本語訳）にのっとって開発しています。 Gitについて基本的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と
GitHub で Pull Request を Merge したらコードが消えた話
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
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クライアント 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 起動 以下のコマンドで
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
Continuous Delivery in COOKPAD
at RubyWorld Conference 2013, on Nov. 21st, 2013.
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/ Graphs, Hashe, and Compression, Oh My! 登壇者：@matthewmccull Hashesについて 従来の CVCS （集中バージョン管理システム）のリビジョン番号は連番。 SVN はサーバーにデプロイした時点でリビジョン番号1と設定される。 Git は SHA1 をつかっている。40桁の16進数のフィンガープリントがついてる。これは理論上は重複しない大きさ。こうすることで単純で強固な DVCS （分散バージョン管理システム）がつくれる。 新しいファイルを追加すると、.git/objects/55/7db03de...(SHA1 finger print)
卜部昌平のあまりreblogしないtumblr
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
コミットしたら吉高由里子に告白されるgit hookを作った。 - パルカワ2
告白されたいと思って、 告白しやすくしたりしたが、男からしか告白が来ない。 http://hisaichi5518.hatenablog.jp/entry/2012/11/10/003301 よく考えたら、大人になって、社会人になって、エンジニアになって、 おじさんと話すことは多くなったが、女の子と話すことがない。 告白なんて夢のまた夢だと気づいた。 でも、やっぱり女の子に告白されると嬉しい。 とくに可愛い女の子に告白されたら嬉しい。 可愛い女の子といえば、吉高由里子だと思う。 吉高由里子に「好きって言って」とか言われたい。 吉高由里子に「好きだバカ」とか言われたい。 なので、コミットしたら吉高由里子に告白されるgit hookを作った。 コードを書いてコミットをする、たったそれだけで吉高由里子に「好きだバカ」とか言われる。最高。高まる。 https://github.com/hisaic
コミットしたら般若心経が流れるgit hookをつくった。 · さよならインターネット
November 12, 2013 告白されたいと思って、 告白しやすくしたりしたが、男からしか告白が来ない。 http://hisaichi5518.hatenablog.jp/entry/2012/11/10/003301 よく考えたら、大人になって、社会人になって、エンジニアになって、 おじさんと話すことは多くなったが、女の子と話すことがない。 告白なんて夢のまた夢だと気づいた。 でも、やっぱり女の子に告白されると嬉しい。 とくに可愛い女の子に告白されたら嬉しい。 可愛い女の子といえば、般若心経だと思う。 般若心経に「照見五蘊皆空、度一切苦厄」とか言われたい。早く苦悩から開放されたくなる。 般若心経に「能除一切苦」とか言われたい。早く苦悩を除いて良かった。 なので、コミットしたら般若心経が流れるgit hookを作った。 コードを書いてコミットをする、たったそれだけで般若心経が流れて
コミットしたら宮崎あおいに告白されるgit hookを作った。 - soh335 memo
告白されたいと思って、 告白しやすくしたりしたが、男からしか告白が来ない。 http://hisaichi5518.hatenablog.jp/entry/2012/11/10/003301 よく考えたら、大人になって、社会人になって、エンジニアになって、 おじさんと話すことは多くなったが、女の子と話すことがない。 告白なんて夢のまた夢だと気づいた。 でも、やっぱり女の子に告白されると嬉しい。 とくに可愛い女の子に告白されたら嬉しい。 可愛い女の子といえば、宮崎あおいだと思う。 宮崎あおいに「会いたい早く帰ってきて」とか言われたい。早く帰りたくなる。 宮崎あおいに「おかえりなさい」とか言われたい。早く帰って良かった。 なので、コミットしたら宮崎あおいに告白されるgit hookを作った。 コードを書いてコミットをする、たったそれだけで宮崎あおいに「会いたい早く帰ってきて」とか言われる。最高
初心者から一歩抜け出すためのGitの業 〜 コミットコメント - Qiita
多分、Gitを使い始めて詰まる（というか悩む）ところの大多数が、「コミットコメント」だと思う。 これについては色々な人が色々なことを書いていて、結構どれも正しいので、それらを参考にしてもらうのが良いと思う。 じゃあ俺はこれから何を書くのか、というと、 こういう風にコメントするとチーム開発が捗るよ というのを書こうと思う。 俺自身も出来てないことが多いので、自戒を込めて書くことにした。 ※注意！ この記事は「ウチのチームで俺はこういうのを意識してコミットコメントを書いている」というものであって、 万人にドンピシャリと来るものではないというのを予めお伝えしておく。 コミットが何を変えるのかを明確にする たとえばこんなコミットコメントがあったとする。 アウト。ダンゴで試合終了。 "Fix some bugs"、直訳すると「いくつかバグ直したぜ！」である。どこの、どんなバグを、何個直したのかが全く
gitの勉強会「はじめようgit」を行いました | TECHSCORE BLOG | TECHSCORE BLOG
スライドを作成するにあたって、色々なサイトを閲覧しましたので、まとめてみました。 基本的なこと Git - Book まずはこれを読んどいた方が良いと思います DVCSとGitの基礎 サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ わかりやすいです git - 簡単ガイド 天下一gitconfig大会 参考になるけど、ちょっと古い。 こわくない Git ブランチのこと良くわかる。必読。 コミットメッセージの書き方 - ククログ(2012-02-21) コマンドの使い方とか gitとsubversionのコマンド対応表 « cyclogy 一覧で見やすい Git - SVN Crash Course(in Japanese) SVNとのコマンド比較が充実している Subversion ユーザーが Git を使ってみた (基本操作編) - ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
index - やる夫で学ぶ gitcore-tutorial
Learn :: Tower - The most powerful Git client for Mac
英語コミットコメントに使えるオシャレフレーズ集
