git-svnでSVN→Gitへの移行をやってみたログ - Qiita
※本稿は諸事情により過去の投稿を再投稿したものです。 はじめに git-svn を使うと、素直な SVN リポジトリーなら簡単に移行できますが、実運用してきた SVN リポジトリーを移行する際はつまづくことも多々あります。 また Git リポジトリー化ができてもブランチやタグは手作業で作ることになります。 今回、たまたま移行を検討する機会があったので、その予行作業のなかで得た知識をメモしておきます。 作業を行ったクライアント環境は Ubuntu 14.04 / Git 1.9.3 です。 SVN リポジトリーは HTTPS でアクセスできる状態です。 移行の第一歩 まずは SVN リポジトリーからローカル環境に Git リポジトリーを作成します。 git svn clone または git svn init + git svn fetch を使います。 ヘルプや Book にも記載されてい
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Gitでpushまでしたmasterブランチを巻き戻す - おひとりさま勉強会
Gitで管理しているリソースで、 デフォルトでpullしたmasterリポジトリで、 間違ったcommitをたくさんしてしまった。。。 今後このようなことがないように気をつけようと思うけれども、 一応手順はメモっておく。 １． git reflog で巻き戻したい場所を確認する。 こんな感じのがずらずら出てくる。 0ffb888 HEAD@{0}: commit: modified: index.php 3854ed7 HEAD@{1}: commit: modified: js/mage/adminhtml/sales.js ２．巻き戻し個所を指定してreset git reset --hard HEAD@{19} ３. push したいのだけど、当然のごとくエラー remote: error: denying non-fast-forward refs/heads/master (yo
git rebaseを使うときのルール | Yakst
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
GitHub のプルリクエストを fetch しとくと便利 - HWPS別館
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
Gitによるバージョン管理入門 for windows
はじめに もうだいぶ前に、当時主流だったバージョン管理システムである、CVSを研究して開発に使用したことがあります。 周りに知っている人がいなかったので、ネットで調べたり、本を買ってきて読んで勉強したりましたが、最初のうちは、ぜんぜん分からなくて、かなり苦労しました。 今回、Gitについて調べていて、やはり同じように、はじめは、ぜんぜん分からない状態が続きました。 CVSの時も、今回のGitの時も、「ううん、僕にはバージョン管理を理解する才能が欠落しているのだろうか？ もうやめちゃおうか」とも思ったのですが、「えいくそ！」と何とかがんばって続けて、 最終的には理解できました。 この２つのバージョン管理システムの研究で苦労した経験から、 なぜ最初は全然理解できなかったのか、その理由が分かりました。 皆さんがコンピュータのソフトで分からないときは「こんなことがしたい」と思いながら ヘルプを見た
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
git rebaseについてのtips | けーこ in サンフランシスコ
エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn! マスターとのマージ時には事前にgit rebaseを使う gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。 Merge branch ‘master’ of git://github.com/hogehoge これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。 このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最
Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
git-助けてというすごく便利なエイリアスを作った - 鳩舎
こんばんは！暑い！ ということで今日はgitのすごく便利なエイリアスを作りました。 Git-助けて https://github.com/rosylilly/git-tasukete という、超便利コマンド集です。 使い方はホームディレクトリあたりにクローンしてきて、パスを通しておくだけです。 するとあら不思議、ターミナルに $ git 助けて と打つだけで、助かりたい時の場合がリストで出てきます。 後はそのうち、目的の状況のモノをターミナルにコピペするだけです。ほらね $ git mergeを取り消したい はい、マージが取り消せました。よかったよかったー！ こんな困った場合にも対応してください！というのはGitHubのissueか、コメント欄にて受け付けてます！
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
git初心者向けのTipsなど - os0x.blog
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
layer8.sh
Log in with Atlassian account
Something went wrong.
GitHub Flow (Japanese translation)
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ
Site Under Maintenance
git でまだpushしていないcommitを確認する方法って何でしたっけ？ - Qiita
