LinuxとBitKeeperとGitの関係 | Yakst
Linuxは過去にバージョン管理システムとしてBitKeeperを使用していて、それがGitに置き換えられた経緯について 「LinuxとBitKeeperとGitの関連について書かれたいい記事ってありますか？」という質問へのOscar Bonilla氏の回答 いい記事は見た事ないけど、どういうことがあったのか簡単に書いてみます。 90年台後半のLinuxプロジェクトは、問題を抱えていました。非常に多くの開発者が関係している一方で、彼らがハッピーになるようないいシステムは存在していませんでした。LinusはCVSについて調査しましたが、最悪という判断を下し、結局tarballとdiff、patchを使っていました。これは彼の取り巻きたちの間ではうまくいきませんでした。なぜなら、多数の開発者から送られてくるパッチをLinusが適用できるような巨大パッチに統合して、コンフリクトを見つけて、そして
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
BitKeeperがオープンソース化された付記DVCSの歴史
BitKeeper BitKeeperは最初の分散ソース管理システムである。今後はオープンソースのApache 2.0ライセンスとして提供される。 BitKeeperは高速で、エンタープライズレディな、分散ソースコード管理であり、大きなプロジェクトから小さなプロジェクトまでスケールする。 「最初の」という主張には語弊があるが、DVCSの歴史を考えると、あながち間違いでもない。 DVCS(分散バージョン管理システム)を最初に実装したのは、Sun WorkShop TeamWareである。 Sun WorkShop TeamWare - Wikipedia, the free encyclopedia これは名前通り、Sun Microsystemsによって開発されたDVCSで、その主要な開発者として、Larry McVoyがいる。 Larry McVoy - Wikipedia, the f
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
Chris Ball » Announcing GitTorrent: A Decentralized GitHub
(This post is an aspirational transcript of the talk I gave to the Data Terra Nemo conference in May 2015. If you’d like to watch the less eloquent version of the same talk that I actually gave, the video should be available soon!) I’ve been working on building a decentralized GitHub, and I’d like to talk about what this means and why it matters — and more importantly, show you how it can be done
Gitを大容量バイナリファイルへと拡張するGit Large File Storage
12のソフトウェア・アーキテクチャの落とし穴とその避け方 成功するソフトウェアアーキテクチャを開発するのはシンプルだが、簡単ではない。QARを理解し、QARを最大限に満たすトレードオフを理解し、実行するには、洞察力と経験が必要であり、その多くはアーキテクチャ自体の実験を繰り返すことで集めなければならない。プロセス自体は単純だが、考慮すべきトレードオフはしばしば難しく、簡単な答えはめったにない。
GitHubのPrivateリポジトリをChef経由でcloneしようとしたらハマった
自分のinit.elや.zshenvはGitHubのPrivateリポジトリで管理しています。 masutaka.netでも同じ設定を使いたかったので、Chef経由(実際はKnife Solo経由)でgit cloneしようとしたら結構ハマったので、メモしておきます。 ぶっちゃけmasutaka.netに秘密鍵をおけば、ハマることはないです。でも セキュリティ的にあんまりなので、sshのforward agent機能を使い、ロー カルの公開鍵をリモートでも使うようにします。 (1) sshのforward agentを設定する# やり方は簡単で、ローカルの~/.ssh/configに以下を追加し、ローカルで ssh-addコマンドを実行するだけ。 Host masutaka.net ForwardAgent yes この状態でmasutaka.netにsshログインし、git cloneす
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
Gitreceive - r7kamura per second
gitreceive という、git push時に任意の処理を実行する為のツールがある。 Dokku の中で同様の仕組みが使われており、 git push時にbuildpacksでアプリをbuildしDockerコンテナの中で動かす、 という機能を実現している。 認証機能 gitreceiveはSSH公開鍵登録用インターフェース、 及び公開鍵を利用した簡易的な認証機能を持っているが、 公開鍵を登録したユーザからのPushのみを許可するというもので、 Pushするアプリケーションごとに別々の権限を与えるということは出来ない。 forced command gitreceiveはSSHのforced commandと呼ばれる機能を利用している。 forced commandを使うと「SSH接続時に何をするか」という情報を、 クライアント側ではなくサーバ側で指定出来る。 OpenSSHでは、au
libgit2
libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language that supports C bindings. Cross-Platform Linux, macOS, iOS, and Windows are fully tested and supported. Portable C Written in a well-supported subset of C99. Builds in GCC, Clang and MSVC. Minimal
gitでブランチを切り替えた時に何かする(例えばrbenvでRubyのバージョンを切り替えたり) - ( ꒪⌓꒪) ゆるよろ日記
タイトルの通りのことをやりたかったっぽいので。 例えば、現在のRubyのバージョンはREE 1.8.7だけど、次回リリースからは1.9.3にあげることになっている場合なんか、masterブランチはREE使うけどdevelopブランチは1.9.3で動作させる必要があるっぽいけど、checkoutするたびにrbenv localとかするのダルいしよく忘れるので全力回避したいっぽいです。 で、どうやるかというと、gitのhookでpost-checkoutというのがあり、そこに色々書くとふんわりとやってくれる風味っぽい。 gitリポジトリの.git/hooks/post-checkout をこんな風に書いておくとよいっぽい。 #!/bin/sh # Change ruby version CURRENT_BRANCH=`git rev-parse --abbrev-ref HEAD` RUBY_
git difftool --dir-diff が便利すぎて泣きそうです
Git の 1.7.11 から git difftool コマンドに --dir-diff というオプションが追加されたのですが、これがライフ チェンジングだと思ったので紹介します。 --dir-diff 登場以前の git difftool は「ファイルごとに順番に差分を表示していく」ことしかできず、使い勝手はいまいちでした。それが、--dir-diff オプションの登場で状況が一変したわけです。 こんな感じの使い心地だよ ある Git レポジトリーで dir1/a.txt と dir2/c.txt を編集したとしましょう。 この状態で git difftool --dir-diff または git difftool -d を実行してみると・・・。 はい、差分のあるファイルが一覧で表示されました。 (difftool に WinMerge を設定して、メニューから [ツリー表示] を有効
tig なんて目じゃない！ Git のログ系 Vim プラグイン gitv ＆ gitv をGit 統合インターフェース化する最強の設定 - 反省はしても後悔はしない
この記事は Vim Advent Calendar 2012 の 168 日目の記事です。 昨日は id:yonchu さんの accelerated-smooth-scroll という Vimプラグイン を作った (Vim Advent Calendar 2012, 167日目) - よんちゅBlog でした。 はじめに 最近、Git のログを見る系のエントリが多い気がします。今回の Vim Advent Calendar でも はじめての unite source(unite-tig) - Design x Verification vac143 - YouTube Vimでgitのログをきれいに表示する - derisの日記 という記事がありましたし、また最近 git? tig! | Atlassian Japan CUI で Git 使うなら入れておきたいツールまとめ | バシャロ
gitで一部のディレクトリだけチェックアウトする - Qiita
git 1.7からsparse checkout機能が利用できるらしい。 ざっくりとした使い方は以下の通り、 $ git clone リポジトリURL hoge $ cd hoge $ git config core.sparsecheckout true $ echo "hoge.txt" > .git/info/sparse-checkout $ git read-tree -m -u HEAD こうするとワーキングディレクトリ下はhoge.txtファイルだけチェックアウトされる様になるらしい。 これまで制作部スタッフにhtmlファイルを編集してもらうのに社内共有フォルダでファイルの受け渡しをしていたんだけど、この機能を使ったらもう少しスマートにならないかなと考え中。 gitスキルのない制作部スタッフにいきなり今日からgit運用にします。ってのは、ハードル高すぎるので、gitアクセスは
【翻訳】あなたの知らないGit Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - x-motemen/ghq: Remote repository management made easy
TechCrunch
gitのdiffを見やすく表示する - Qiita
