仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Movable Type のコード管理についてまとめてみました-Six Apart ブログ｜オウンドメディア運営者のための実践的情報とコミュニティ
やっと暖かくなってきて桜もチラホラと咲き始めましたね。こんにちわ、シックス・アパートの高山です。 さて、今回はMovable Type に限らずですが、開発の根幹と言えるコード管理についてお話をしたいと思います。 ご存じの方も多いかと思いますが、Movable Type は現在 github 上で開発が行われています。（セキュリティ・フィックスの際には、社内のgitサーバでひっそりと開発が行われます。）gitに移った事を期にブランチ管理のやり方も変えています。 ちなみに、現時点でのブランチはこうなってます。 % git branch -a remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/develop-backuprestore remotes/origin/feature-assetdr
デザイナーが RailsとGitのことを少し知ってると色々捗る
The document contains a series of dates from 2011-6-22 repeated many times. Between some of the dates are short phrases such as "Don't Repeat Yourself" and "Convention over Configuration". The overall document does not appear to have a clear purpose and consists primarily of a date repeated with occasional unrelated text fragments.Read less
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
.gitconfigに設定してるaliasなどのまとめ - ( ꒪⌓꒪) ゆるよろ日記
22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
Redmineとは
Redmineとは、オープンソースのプロジェクト管理ソフトウェアです。誰でも自由にダウンロードして利用できます。 「プロジェクトの進捗を管理したい」、「チームのタスクをメンバーと共有したい」、「順調に進捗しているのかチームで共有したい」、このような会社やチームで取り組むべき業務やプロジェクトの作業を記録・管理したり社内で情報共有ができます。 例えば、チームでシステム開発を進める場合に誰がいつまでに何をやるのか、現在どのくらい進んでいるのかをRedmineに記録することで進捗状況を明らかにし計画通りに進むよう支援します。 デモサイトをみる 登録なしですぐにRedmineを操作できます Redmineの中核機能は「チケット」機能です。やるべき作業を「チケット」に登録し管理します。上の動画でもRedmineの機能をご紹介しています。 チケットはガントチャートやカレンダー、ロードマップなどで表示が
gitosis - Git リポジトリ群の管理とアクセス制御 vol.0 - openbooth
最近流行りの Git。現段階で github 等のホスティングサービスを使う人が多いと思います(もしくはローカルだけで使ってるか)。github のようなホスティングサービスを使っている場合は、github 自身がリモートリポジトリの管理をしてくれるため、ssh の鍵を github に登録するだけで僕たちは Git の恩恵に預ることができます。リポジトリの操作は大概 github のウェブアプリケーション越しで済んでしまいます。楽です。 しかし、このリモートリポジトリを自前のサーバでホストする、あるいは企業のバージョン管理ツールとして Git を使うとなると俄然敷居が高くなるように感じます。github のウェブアプリケーションとその周辺ツールがオプソで公開されていれば非常に嬉しいのですが、まぁ現時点ではそんなおいしい話はない訳で、ないものねだりになってしまいます。 そのため、特に企業で
せっかちな人のための git 入門 - git をインストールし、共同で開発できる環境を整えるまで - 僕は発展途上技術者
subversion に代わる新しいソース管理システムということで git が注目されているようだ。 » Git - Fast Version Control System subversion と大きく違うところは、分散されたレポジトリがローカルマシンに置かれている点。これは、ネットにつながっていなくてもソースをコミットできるということで、最近は電車のなかでもコードを書いたりする僕にはうってつけ。 マニュアルやチュートリアルは充実しているのだが、僕はとりあえず最初にツールを触ってみて、ざっと全体像をつかみ、それから細部を調べたい質なので、もっとてっとり早く体験できるガイドを探したところ、あまり適切なものが見つからなかった。 そこで、レポジトリを作り、それをリモートにあるサーバーに置いたあと、subversion で言えば svn commit や svn update などにあたるコマン
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
Gitorious - Gitorious
aleksi pushed 28 commits to ~aleksi/gitorious/gitorious-aleksi:master master changed from 9ee078e to 2bf29ca Johan Sørensen 2bf29ca: Implement a more conservative way of running git-gcJohan Sørensen f94aefb: Fix toggling of merge request help and markdown helpJohan Sørensen 4bda0d8: jQueryize a few dollar-sign function callsJohan Sørensen c53455e: Display a warning/note message when there's a larg
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
