図解 Git
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版
9/18（土） 15：30～ GitとGitHubを体験しながら身につける勉強会（名古屋） : ATND 行ってきました。 なんかいろいろと話すことになったんですけど、あの場で言いそびれたこととか、もっとこう説明してればよかったなぁ、って部分の補足も兼ねたエントリです。 長文注意。 ショートカット git add の話 git add -p/git reset -p の話 リビジョン番号がない話 ブランチの話 git-completion の話、__git_ps1 の話 コミットの指定の話 reset の話 rebase と merge の話 公開したものの rebase の話 stash の話 TortoiseGit、HG、SVNのはなし 全体を通して git add の話 Git と SVN では、add に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
Well, I'm ... sorry...
Gitとはどう違うのかと聞くと、「Git!? そんなの学生しか使わないよ」と一刀両断。真剣な大規模開発を行っているところならPerforceを使ってるのだといいます。これを聞いて、グーグル本社でGitについて講演したリーナス・トーバルス氏が、グーグルがPerforceを使っていることを聞くに及んで「それは、、、悪かった」（I'm....sorry...）と苦笑いしたニュアンスが少し分かった気がしました。それまでほかのSCM（主にSubversion）の悪態を付きまくっていたリーナスも、Perforceには、ごめん、かなわないよという意味だったのかもしれません。 言葉尻をなるべくあいまいにする日本人のボクならともかく、あのはっきり辛口のLinusがそんなコトを言うわけがなかろう。上は単なる的外れな誤訳で、あの、I'm... sorry... は「それは、、、お気の毒に」である。大体、それでな
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
gitのcommit objectの中身 - はこべにっき ♨
commitって結局なんなの?というはなしです．commitの中身を表示してデータの実体を見てみます． あわせて読みたい: Git for Computer Scientists 適当なcommitのobject id ( = SHA1 )を得るためにgit show-refでmasterブランチのHEAD commitのobject idを得ます． $ git show-ref refs/heads/master # master の HEAD の commit の obeject id を表示 216640790e88d6fd794a96fd1a7c81dd2ad86981 refs/heads/master 以下のようにして，git cat-file でcommitの内容を表示できます．treeにはcommitが発生した時点でのファイルツリーを再現するための情報が入っています．par
Repo って何だろ? -- 複数 git リポジトリーのためのツール
Google が repo というツールをリリースしている。これは、Google が開発している Android プロジェクトのためのツールなのだけど、Android 専用のツールといふわけでもなさそうなので、少し調べてみた。 Get source (Android Open Source Project) Using Repo and Git (Android Open Source Project) repo は、git を補完するツール。 repo の仕事は主に 2 つ。1 つは、「複数の git レポジトリー」を管理すること。もう 1 つは、git のレポジトリーを取って来たり、レビュー・サーバーに変更点を送ったりということ (特に複数レポレトリーをサポートしている点がミソ)。 何が嬉しいの? 普通、バージョン管理ソフトは、一つのリポジトリーで一つのプロジェクトを管理する。開発規模
gitで双方向にmergeしてるとひどいはまり方をするときがある件 - はこべにっき ♨
gitで双方向にmergeしてるとぎっとぎっとにされる件 gitで，ブランチきって双方向にmergeしたりされたりするときには注意しないと，身に覚えのない衝突しになやまされたりする．自分があまり関知していないコードの衝突を解決する必要がでてきたりして，バグのもとになる． (23:11まきもどりうんぬんはちょっと違う気がしたので削除) 解決方法としては， masterに自分のブランチをmergeする直前には，かならず自分のブランチにmasterをmergeする 自分のブランチにmasterをmergeしない のどちらかが妥当そう． 以下つらつらと書いてあるけどスルー推奨．良くわかってないところも多いのでまちがってたら教えてクダサイ．というか，git-mergeのしくみをちゃんと理解できてないので，変なこと行ってる気がしてきた． 追記: gitで双方向mergeしたときに起こった問題を再現 -
git submodule - みずぴー日記
http://d.hatena.ne.jp/woremacx/20080308/1204986198のように、gitで外部レポジトリを扱えるようにする方法。 外部レポジトリの追加 git submodule addすると、外部レポジトリをサブモジュールとして取り込めるようになります。 # cloneする $ git clone git://example.com/repos/private/ $ cd private # git://example.com/repos/external/を追加する $ git submodule add git://example.com/repos/external/ # commitしておく $ git commit -m "Add submodule" $ git push 外部レポジトリ内での作業 外部レポジトリで作業したときは、そこでコミットする
git型の共同作業とSVN(CVS)型の共同作業の違い - Pixel Pedals of Tomakomai
ずっと gitとsvkの違いってなんなのよ？ と思ってたんですが、この図とか説明読んでようやくわかりました。 Gitでは旧来のCVS型とGit型の二つの共同作業のモデルが使えます。これが混乱の元でした。 Gitのすごさを本当に体感するなら、gitを使うだけでは不十分でGit型のモデルにそって開発することが必須です。 CVS型 従来のSVN(CVS)のモデルです。pullをしてきて、pushで更新を戻します。 1つの公開リポジトリに対し、複数人がpushを行う pushにより他の人と競合するかも メインのリポジトリにpushすることを目指す 能動的 → 悪意のあるpushも可能 → "コミッター"を絞る必要あり Git型 githubっぽいモデルです。pullをしてきて、pullで更新を持って行ってもらいます。 全体がpullでまわるため、pushがプライベートな操作として隠蔽されてるのがポ
~nabeken/diary/ : git で dotfiles を を管理してみる
Posted on Fri Oct 17 00:45:38 +0900 2008 by nabeken 注意 模索しながら書いているので、いろいろと最適なモデルを探っています。変更点は一番したのログを見てください。 使っていると、ラップトップ、デスクトップ、サーバでそれぞれテンプレートを1つ保持するのがよいという結論に至りました。 まず、手元で使っているのを git リポジトリへ入れます。最初はひとまずすべてを master へ放り込みます。 自宅デスクトップ ラップトップ 学内マシン バイト先のマシン の4つの環境があります。それぞれは共通したものもあれば、環境特有の設定も入ります。1つのリポジトリで、それぞれの設定はブランチで運用してみることにします。 まず、テンプレート用ブランチを作ります。 # git clone git.example.org:Repo/moge # cd mog
githubでforkしたリポジトリから本家にpush - はこべにっき#
昨日いっていた問題が解決したので，あらためてgithubでforkしたリポジトリから本家にpushする方法． 本家にコミット権があるのが前提なので，ふつうは本家をcloneして作業すれば問題ないです．ただ，途中までforkで開発してたんだけど，ある日，コミット権をもらったりして本家に反映したいような時には便利です． 以下folkしたリポジトリのcloneのmaster branchにて， # remote リポジトリを設定する $ git remote add jugyo git@github.com:jugyo/termtter.git $ git fetch jugyo # git pullして本家の変更を取り込む $ git pull --rebase jugyo # 変更をgit pushする $ git push jugyo いろいろまわり道したけど，すごいやったことある，コレ．
checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - （ひ）メモ
唯一の中央レポジトリと複数のcheckoutするノードというトポロジの場合、checkoutしたファイルのmtimeがノード間で同じ時刻(当該ファイルがcommitされた時刻)になっているとなにかと都合がいいです。 例えば、Webアプリのデプロイを中央レポジトリからのcheckout(やupdate)で行う場合を考えます。もし、内容が同じなのに複数あるアプリサーバの間でmtimeが異なってしまっていると、 サーバごとにETagヘッダの値が異なってしまう ※Apacheの場合、FileEtagディレクティブを調整(mtimeを見ないように)することによって統一可能ではあります サーバ間でrsyncをかけると無駄なファイルコピーが発生する 内容が同じににもかかわらずmtimeが異なるせいでコピーが発生する ※--size-onlyオプションでmtimeを見ないようにして回避可能ではあります と
Simplistic Complexity
Rmagick. It sucks, I know. We all hate it. But you have apps that depend on it and haven't changed that yet. So you need it installed for development. And you hate installing it. But really, its not that installing RMagick sucks, its installing ImageMagick that sucks. Its hard. But the only thing worse than hard, is stupid ass MacPorts. So all I hear is people complain over and over about having t
Big Sky :: SSHポートが通らなくてもgithub.comにpushする方法
« ニコニコ動画をダウンロード出来るPerlモジュールWWW::NicoVideo::Downloadを試してみた。 | Main | ニコニコ動画をダウンロード出来るプログラムをC言語で作ってみた。 » 皆さん既に知ってたら御免なさい。ずっと知らなかったのでgithubには手を付けてませんでした。 githubは、cloneするとき # git clone git://github.com/yappo/konnitiwa.git の代わりに # git clone http://github.com/yappo/konnitiwa.git とgitをhttpにするとclone出来るのは知っていたのですが、pushはsshを使うのでport 22が開いてないとpush出来ない物と信じ込んでいました。 が、今日解決しました。以下私がWindowsで行った手順 Windowsじゃない人は最初の
せっかちな人のための git 入門 - git をインストールし、共同で開発できる環境を整えるまで - 僕は発展途上技術者
subversion に代わる新しいソース管理システムということで git が注目されているようだ。 » Git - Fast Version Control System subversion と大きく違うところは、分散されたレポジトリがローカルマシンに置かれている点。これは、ネットにつながっていなくてもソースをコミットできるということで、最近は電車のなかでもコードを書いたりする僕にはうってつけ。 マニュアルやチュートリアルは充実しているのだが、僕はとりあえず最初にツールを触ってみて、ざっと全体像をつかみ、それから細部を調べたい質なので、もっとてっとり早く体験できるガイドを探したところ、あまり適切なものが見つからなかった。 そこで、レポジトリを作り、それをリモートにあるサーバーに置いたあと、subversion で言えば svn commit や svn update などにあたるコマン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TEXTdrop｜翻訳・オンラインカジノ 日本円のプログラミング