This domain may be for sale!
gitで双方向にmergeしてるとひどいはまり方をするときがある件 - はこべブログ ♨でごちゃごちゃ言っていた状況を再現するコードを書いてみた. 実行すると,カレントディレクトリにmerge_testというリポジトリに,問題になっている状況を再現する.だいたいコメントに書いてあるます merge_test.sh · GitHub 研究室の友達といろいろ議論した結果,結局,gitがなにか悪さをしているとかではなくて,ブランチをどう運用するかが問題なんだろうということで落ち着いた. いったんexperimentalにmasterをmergeするとmasterで行われた変更がexperimentalに含まれることになる.その後,masterにexperimentalをmergeするときには,master関する衝突とexperimentalに関する衝突の解消の両方をする必要がでてくる可能性がある
先日のデブサミ2009で発表した、はてなの開発戦略 (すごい名前だ…) のプレゼン資料を公開します。前半は主に git の話で、後半ははてなブックマークリニューアルの、Perl 層の開発をどんな感じで行っていったか、という話です。 デブサミ2009 はてなの開発戦略View more presentations from hotchpotch. はてなの git では、中央のマスタレポジトリサーバがあって、そこから各自 clone / fetch して開発を行ってるので、完全に github のような分散のメリットを生かしているわけではありません。 しかし完全に分散を生かさずとも、git に移行したメリットは十分にあって、資料の中でもふれていますが、やはり一番便利なのが git のブランチ機能です。もうこれ無しでの開発は考えられないなぁ、ぐらいで、さくっとブランチ切って開発、ブランチの切り
ずっと gitとsvkの違いってなんなのよ? と思ってたんですが、この図とか説明読んでようやくわかりました。 Gitでは旧来のCVS型とGit型の二つの共同作業のモデルが使えます。これが混乱の元でした。 Gitのすごさを本当に体感するなら、gitを使うだけでは不十分でGit型のモデルにそって開発することが必須です。 CVS型 従来のSVN(CVS)のモデルです。pullをしてきて、pushで更新を戻します。 1つの公開リポジトリに対し、複数人がpushを行う pushにより他の人と競合するかも メインのリポジトリにpushすることを目指す 能動的 → 悪意のあるpushも可能 → "コミッター"を絞る必要あり Git型 githubっぽいモデルです。pullをしてきて、pullで更新を持って行ってもらいます。 全体がpullでまわるため、pushがプライベートな操作として隠蔽されてるのがポ
近年急速にユーザーを増やしているバージョン管理システムに「Git」がある。GitはLinuxカーネルの開発リーダーとしても知られるLinus Torvalds氏らが、Linuxカーネルの開発に使用する目的で開発した分散型バージョン管理システムで、現在ではPerl 5やRuby on Rails、Android、Wine、X.orgなど、さまざまなプロジェクトで採用されている。 本特集では、Gitを使用するのに必要な「分散型バージョン管理システム」の基本的な考え方を紹介するとともに、Gitの導入方法やWindows環境での利用方法、Subversionなどほかのバージョン管理システムとの連携など、Gitを活用するためのテクニックを紹介する。 分散バージョン管理システムGit入門 2009年2月6日 バージョン管理システムと言うとSubversionやCVSが有名だが、近年急速にユーザーを増や
git はおれの嫁 ( ないと生きていけない的な意味で ) 。まだ以下で足りてる感じ。最近 git のまとめが多いけど実際に自分でまとめないとわからなくなりそうというだけ。 git init / git clone <repository> 新しく file を作った場合 git add <filename> git commit 既存 file の編集のみの場合 git commit -a さっきまでの変更をなかったことにしたい場合 git checkout -- <filename> ( 個別に file 指定 ) git reset --hard HEAD ( 変更すべてを一気に ) 直前の commit を失敗した場合 ( add を忘れたとか commit message ミスったとか ) git reset --soft HEAD^ 変更は残したまま commit をなかったこ
svn に比べると細かい作業ができるんだけど色々覚えなきゃいけないことも多い。 TortoiseSVN から入ったおれにはちとつらいぜ。てか tutorial とか読んでても管理がしたいだけなのに仕組みについて説明されても…、と思わないでもないんだけど管理って行為自体が精度と手間に関して trade-off なのかもしれない。ここらへんもう少し user-friendly というか heuristic な感じでこなれた client が出てくると習得 cost も下がってもっと普及するのかもしれないなぁとか何とか。 とりあえず現在までの流れは大体以下のような感じみたいなので ( きちんとした ) TortoiseGit が作られないかなぁと思いつつ。 手動で source 管理 管理は software がやればいいじゃない ( CVS, subversion ) 直感的な操作で管理するの
git に関する文書。っても全部 http://git-scm.com/documentation にあるのなんだけど。とりあえず全部読んでおくべきなんだけど個人的にこの順番で読むと理解が進むと思う順に挙げる。てかつくづく導入の敷居が高い tool だな。と思ったけど習得曲線ののびが悪いだけで習熟する範囲はそんなに広くないから一度覚悟を決めてしまえば何とかなる感じ。まず local での操作を覚えてそれで生活しつつ branch や remote の管理を覚えていくというのが鉄板な気がするなぁ。 SVN Crash Course http://git-scm.com/course/svn.html svn 関係触ったことのあるひと ( TortoiseSVN 含む ) はまず真っ先に読むべき。というのも svn を使ったことのあるひとにとっては git は紛らわしい単語の使い方をしているの
バージョン管理システムと言うとSubversionやCVSが有名だが、近年急速にユーザーを増やしているバージョン管理システムに「Git」 がある。GitはLinuxカーネルの開発リーダーとして知られるLinus Torvalds氏が中心となって、Linuxカーネルの開発に使用する目的で開発した分散型バージョン管理システムである。2005年に開発が開始されて以来さまざまなプロジェクトでの採用が進み、現在ではPerl 5やRuby on Rails、Android、Wine、X.orgなど、有名な大規模プロジェクトで採用されるに至っている。 本記事では、このGitを使用するのに必要な「分散型バージョン管理システム」の基本的な考え方を紹介するとともに、Gitの導入方法や基本的なGitの使い方について解説する。 分散バージョン管理システムとは? GitはLinuxカーネル開発で用いられることを前提
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
WindowsでGitを使う場合、msysGitというMSYS(Minimal SYStem)ポーティングされたGitを使うのですが、これにはssh-askpassが付いてきません。以前書いた「Big Sky :: Windowsでもssh-agentとssh-addを使ってパスフレーズ入力を省略する。」でご紹介した方法は、開いたコマンドプロンプト内でしか有効になりません。これは新しく起動したコマンドプロンプトに、ssh-agentから引き渡されるSSH_AGENT_PID/SSH_AUTH_SOCKといった環境変数が引き継がれていないのが原因です。これを解決する方法のひとつとして、win-ssh-askpassという物があります。 win-ssh-askpass 1.05 (GANAware) GUI ssh-agent for cygwin. http://www.ganaware.j
git svn clone は svn ログをたどるためでかい svn レポジトリになるととんでもなく時間がかかります。 なのですでに clone 済みの git レポジトリから clone したら簡単じゃんと思って素直に clone してみたのだけど、そのままじゃうまく clone 出来なかったのでメモ。 こんな感じでやればおk # とりあえずレポジトリ作る mkdir test cd test git init # clone git remote add origin http://co-workers-pc/dev/project/.git git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' git fetch git reset --hard trunk # git svn の remote
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する方法. 本家にコミット権があるのが前提なので,ふつうは本家を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 いろいろまわり道したけど,すごいやったことある,コレ.
ソースコード管理システムの機能として、あらゆるファイルの履歴を完全に記録するというものがある。 普通に考えてこれは便利な機能である。だが・・・ 間違えて「公開すべきでないファイル」を公開リポジトリに追加してしまった場合、頭を抱えることになる。 そのファイルを普通に削除したところで、現時点のリビジョンから消えて無くなるだけで履歴をたぐれば取得できてしまうからだ。 Subversionの場合、「特定のファイルを無かったことにする」機能が無いため一度リポジトリをダンプしたのち完全に削除して直近のリビジョンを省いたものをリストアといった手間が必要なようだ。自分の管理しているリポジトリなら面倒なだけで済むが、もしそうでなかったらと考えるとこれはまさに悪夢である。 だが Gitの場合はこういうことが出来るらしい。 Guides: Completely remove a file from all re
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
With git 2.6 it’s now easier than ever to keep track of your work during an interactive rebase. Previously, if you were rebasing interactively and had hit a conflict or stopped to reword a commit, git status would look like this: $ git rebase -i HEAD~5 $ git status rebase in progress; onto 0927cd6 You are currently rebasing branch ‘t… Read More »
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く