svn から git に author 情報を引き継ぎ移行するメモ - 烏賊様
CodeRepos から GitHub に移行するパターンで，両方のレポジトリでユーザ名が同じでも，結局別人扱いされてしまうのでどうしたもんかなぁと思っていたのだけど，こことかこことか見るとマッピングファイルを作ればいいということがわかった． git help svn すると -A(--authors-file) というオプションがあって，これに次のフォーマットでマッピングを記述しておいて読ませるらしい． loginname = Joe User <[email protected]>loginname には svn での名前を書いておけばいい．行区切りで複数のマッピングを書ける． さらに svn.authorsfile という config にファイル指定しておけば良さげだったので，git config --global で登録してみた．これで git svn の度に -A しなくていい．
Post by @tazyamah
なんでかというと、仕事でもプライベート(あまりやってない)でもgitを使っていて、リポジトリがアホみたいな数になると、各リポジトリごとにgit configするのがものすごくめんどくさかった。 んで、.gitconfigでリモートリポジトリ別にuserの設定ができたらよかったんだけど、どうやらできないみたいでorzしてたところ、git config --helpで以下の様な記述を発見。 user.email Your email address to be recorded in any newly created commits. Can be overridden by the GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL, and EMAIL environment variables. See git-commit-tree(1).
WebデザイナーもGit使うといいよって話 | Cherry Pie Web
※この記事では「Webデザイナー」は、「ノンプログラマ」の意味で使っています。 psd、ai などの材料データの管理ではなく、サーバーにアップするファイルの管理の話です。 サルでもわかるといわれても、やっぱりわからない・・・ Web制作をやっている人は、少なからずバージョン管理システムの話を聞いたことがあると思います。 特にGit（ギット）っていうのは、内容まで知らなくても名前くらいは聞いたことがありますよね。 で、ネット上ではバージョン管理システムのメリットに関するブログ記事なんかもたくさんあって、変更履歴をたどれるとか、複数人で同じファイルを修正したりといった時のトラブルに対応できるとか、なんか便利そうだなーとは思っていたわけですが、ずーっと導入は見送ってきました。 その理由は・・・ 「Git入門」とか書いてある記事を読んでも導入方法が書いてあるだけで、実際に使うシチュエーションが思い
submoduleとsubtree-mergingの使い分け - Qiita
gitで外部リポジトリを取り込んで利用するには、submodule(サブモジュール) とsubtree merging(サブツリーマージ)の2手法があります。 私の観測範囲内では、サブモジュールはよく利用されていますが、サブツリーマージは目にしません。 そこで、サブツリーマージを試してみての使い分けや思ったことをつらつらと。 大雑把な要点を最初に書いておく 外部リポジトリを外のものとして取り込むならサブモジュール 外部リポジトリを取り込みつつ、中のものとして手を加えていくならサブツリーマージ git初心者にはサブモジュール(異論ありそう) サブツリーマージ使ってみた github.com/marutanm/dotfiles 中身としては、よくある環境設定ファイル一覧です。 前提として、 tmux.conf(gistにおいていた) vim設定(githubにおいていた) zsh設定(gith
小規模開発には git-flow よりも GitHub Flow で捗る - TMD45INC!!!
これまで CVS や Subversion ではなかなか敷居の高かった「ブランチを切って作業する」というワークフローが、分散型バージョン管理、とくに Git の登場でとても手軽に取り入れやすくなりました。 Git のブランチを活用するためのワークフローとして有名なものに git-flow と呼ばれているモデルがあります。正しい名称は「A successful Git branching model」で、git-flow はこのモデルの導入を補助してくれる Git 拡張の名称だそうです。 A successful Git branching model（@oshow さんによる日本語訳） git-flow の解説～導入までは以下の記事に詳しく書かれています。 git-flow によるブランチの管理 - O'Reilly Japan Community Blog これはあくまで ”モデル” な
【業界注目】CROOZ主催の勉強会“テックヒルズ”が5度目の開催 今回のテーマは？【開発者専用】 | ファミ通App【スマホゲーム情報サイト】
2013年3月22日、CROOZが主催する“第5回テックヒル ズ”が、都内の六本木ヒルズ内アカデミーヒルズで行われた。次世代技術の可能性を追求する開発者向けの技術勉強会として、CROOZが昨年から定期的に実施しているこのイベント。これまで、 “全文検索＆検索を利用したサービスの使命、利用プロダクト、事例紹介”、“「ネイティブアプリ」vs「Webアプリ」これからのアプリケーション開発の トレンド”、“2012..Flashの終焉!? ～Flashの今後を見抜く～”、“UI、UXの衝撃”といった、そのときそのときの旬な開発技術をテーマに、ゲスト見識者を招いてのプレゼン、パネルディスカッションが行われている。 ★前回の第4回テックヒルズのレポート記事はこちら そして、“Go to Git！ ～さらばSVN～”と題した今回のテックヒルズのテーマは、近年ウェブ業界で注目を集め、多くの技術者に認知され
俺々Mavenリポジトリにデプロイする方法 | nagaseyasuhito Daily works.
自分で作ったMavenプロジェクトをパブリックなリポジトリとして公開したくなったことはありませんか？簡単にセントラルリポジトリにデプロイできればいいのですが手間なので今回は野良リポジトリを作り、そこに公開する方法をご紹介します。 POMを書く scmを書く まずはscmを記述して、チェックアウト、チェックインをするリポジトリのURLを記述しましょう。GitHubなら以下のような感じです。 <scm> <url>http://github.com/nagaseyasuhito/fatsia</url> <connection>scm:git:https://github.com/nagaseyasuhito/fatsia.git</connection> <developerConnection>scm:git:https://github.com/nagaseyasuhito/fatsia
いつやるの？Git入門
The document outlines various Git commands and their usages, including initialization, adding files, committing changes, and managing branches. Key actions include committing with messages in Japanese, removing files, resetting changes, and checking out branches. It also describes the process of cloning repositories, fetching and pulling updates, and handling merges and rebases.
gitでマージ作業を中止して元の状態に戻す | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 例えば新機能Xを実装する場合、 X用のトピックブランチを作成し、実装を進めて、完成したら統合ブランチへマージする というのが普通です。 具体的にコマンド例を挙げると以下のようなものになります: $ git checkout -b topic-x master Switched to a new branch 'topic-x' $ $EDITOR $ git add foo.x bar.x baz.x $ git commit -m 'Implement X' [topic-x 0000001] Implement X 3 files changed, 8 insertions(+), 5 deletions(-) $ $EDITOR $ git add qux.x $ git commit -m 'Fix
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
CUI な Git ブラウザ tig を入れてみた - Born Too Late
Git をなかなか使いこなせずにいる私ですが、これはいい ! コンソールから使える git ブラウザ、tig が超便利 Vim に近い操作感で使えるのが Vim 使いには非常に嬉しいところです。以下で、インストール方法と基本操作について紹介します。 インストール インストールは、まずソースコードからやってみたのですが、パッケージが存在することに気づいたので、 aptitude で入れ直しました。 sudo aptitude install tig はい、簡単ですね。 起動する カレントディレクトリを Git のワークツリーに移動して、 tig コマンドを実行します。 $ cd /path/to/work-tree $ tig ヘルプを表示する: h 何はともあれ、わからないことがあればとりあえず h を押してヘルプを調べましょう。 カーソルの移動: j, k Vim ユーザなら、何の問題も
git merge で常に --no-ff - Qiita
# master 上で git merge するときは常に --no-ff git config branch.master.mergeoptions "--no-ff" # git merge するときは常に --no-ff(1.7.6以降) git config --global merge.ff false ## あわせて設定しておくと吉 # master 上で git pull するときは常に rebase git config branch.master.rebase true # git pull するときは常に rebase(1.7.9以降) git config --global pull.rebase true # git pull するときは常に rebase(1.8.5以降) git config --global pull.rebase preserve
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git, maven and jenkins - versioning, dev and release builds workflow
GitHub Flow (Japanese translation)
RubyGems on Twitter: "anchorman (0.5.0): http://t.co/tKixBKSHxD Extract release notes from your git log"
git merge が、必ずエディタをひらいてきてウザい件 - tokuhirom's blog
https://qiita.com/suzukit86/items/2e72c36dc8a776e4b45c
http://www.machu.jp/posts/20130113/p01/
Log in with Atlassian account
GitHub Flow (Japanese translation)