プログラマになら理解しやすいであろうgitの基本概念解説 - Qiita
今どきこんな記事の需要があるのかわからないけど、まだ「プログラマだけどsvn以前の版管理しか使ったことがない、gitに興味ある」という人もきっと残っているので、プログラマ視点で理解しやすいgitの考え方の紹介を。 svnの履歴は配列、gitはリスト データを並べた構造の表現の仕方として配列とリストってのまず習いますよね。 連続したメモリ空間にただ並べるのが配列、各エントリごとにメモリを確保して「隣のノード」へのポインタを各ノードが持つようにするのがリスト。 svnとgitの最大の違いはこれです。svnは履歴を配列として持つから、履歴にリビジョン番号が付きます。gitは各リビジョンが「前のリビジョン」へのポインタを持ったノードなので、番号が付きません。代わりにリビジョンの内容のハッシュ値をIDとして持ちます。 svnの（仮想的な）ブランチは配列、gitのブランチはポインタ ブランチのことは、
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
【GitとSubversionの構造的な違い】GitのブランチはSubversionのブランチとは全く違うモノ～
最近はVCS（バージョン管理システム）のデファクトスタンダードと言っても過言ではないGit（ギット）ですが、まだまだSubversion（サブバージョン）をご利用されているお客様も多く「Git(Bitbucket)に移行したいがSubversionとの違いやメリットがよくわからない。」と言ったご質問をいただくことがあります。 私自身もこれまでの職場ではSubversionもしくはCVSを利用していて、Gitは勉強用のスニペットコードで利用する程度でしたので同様の疑問を持っていたのですが、リックソフトでBitbucketに触れたことでGitとSubversionとの違いやGitの良さを実感することが出来ました。 そこで私が勉強した中でも特にGitを理解することに役立ちました。GitとSubversionの構造的な違いについてお話ししたいと思います。 今回のブログではGitコマンドの説明や使い
GitからSVNへの移行 - Qiita
これは何？ git から SVNへリポジトリを移行する場合の手順について調べた覚書 手順 SVN 事前準備 SVNリポジトリの作成 SVNリポジトリに、trunk, tags, branchesフォルダーを作り、コミットする。 svnリポジトリをクローン。 git svn clone -s [your-svn-path] ※[your-svn-path]はhttp://xxxxx:8969/xxxx/svn/xxxx/ 形式でOK migration用ブランチの作成 git checkout -b migration 移行したいデータを持ってくる git pull --rebase [your-git-path] ※[your-git-path]はhttp://xxxx.xxx/xxx/xxx.git 形式でOK svnのコミット（Trunk, Tags, Branchesを作ったコミット
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 にも記載されてい
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
SubversionからGitへ移行してみた - Qiita
結構はまったし、後日別のリポジトリを移行することがありそうなのでメモを残しておきます。 前提・事前準備 一旦、ローカルのWindows上のGitに移行してからbareリポジトリ（今回はGitLabだったが手順的には何でもOK）にプッシュする流れ Git for windowsを事前にインストールしておく Subversionのサーバからリポジトリをディレクトリまるごと取得できること git svn clone の最中 svnのパスワードを頻繁に聞かれる問題を色々やってみたが回避できなかったので、ローカルにSVNディレクトリまるごと持ってくる手順で行いました。 今回、一番ハマったのはここでした。 作業はGit Bashから行いました。 手順 Subversionのサーバからリポジトリのディレクトリ丸ごと取得してローカルのWindows上の配置する。 今回はC:¥temp¥にmyappリポジト
28,000 コミットあるSVNリポジトリをGit(GitLab)に移行した話 | バシャログ。
こんにちは、今年は2017年ですね。tanakaです。 このたび、2009年からコミット履歴のあるプロジェクトのSVNリポジトリをようやくGitに移行しました。 その手順やハマリどころについてまとめておきたいと思います。 移行前と移行後の制作フローとか このSVNリポジトリは、開発用ブランチ trunk とリリース用ブランチ branches/RB の2本が常設してあり、 trunk でリリース可能になったコミットだけをCherry pick で branches/RB にマージする運用をしており、 マージしないコミットが増えると衝突が発生したり、時間経過で差が増えていき辛い感じになってました。 そこでGit(GitLab)に移行することにしました。 移行にあたり、ブランチ戦略としてGitHub Flow を導入しました。 master への直接のプッシュは禁止し、すべてマージリクエストで
「Subversion」ユーザごとにリポジトリに対する権限を設定する方法 - プログラム日記
Subversion でリポジトリごとにユーザに権限を設定する方法について調べたので、その時のメモ。 まず、Subversion のインストールを行なう ( なんでインストールからやねんとなりますが、過去のエントリー にインストール書いたものがなかったのでご了承ください )。今回は yum でやった。 yum install subversionリポジトリを作成しておく。 mkdir /var/www/svn/repo1 svnadmin create /var/www/svn/repo1適当な作業ディレクトリで "リポジトリのチェックアウト" - "ファイルの追加" - "コミット" を行なっておく。 svn checkout file:///var/www/svn/repo1/ echo aaa > aaa.txt echo bbb > bbb.txt svn add aaa.txt
svn: E120106: ra_serf: The server sent a truncated HTTP response body. - tmegos blog
症状 svnでcheckoutを行うと、下記のエラーが発生し、checkoutが中断する svn: E120106: ra_serf: The server sent a truncated HTTP response body. 対応 stackoverflowの記事を参考に、svnのcleanupとupdateを行う $ svn cleanup $ svn update エラーが解消され、中断していたcheckoutが再開する
Apache Subversion 1.8 Release Notes
☰ What's New in Apache Subversion 1.8 ¶ Working copy records moves as first-class operation Automatic reintegration merge Inherited properties Repository dictated configuration HTTP client support based on neon has been removed The Berkeley DB-based repository back-end has been deprecated In-memory password caching via GnuPG Agent (Unix client) FSFS size and performance enhancements Storage of aut
SVNサーバ1.8、チェックアウト等でChecksum mismatch error発生時の対応 - Qiita
SVNサーバ1.8へのアップデート後、チェックアウト等の操作時にChecksum mismatch errorが発生するトラブルがありました。 下記対応し解決しましたのでメモしておきます。 現象 SVNサーバ1.8へのアップデート後、チェックアウト時にChecksum mismatch error発生する場合がある。 ・チェックアウト量が極少ない場合は発生しない。 ・SVNクライアント1.8で発生、1.7では発生しない。 (サーバ側はSVN1.8-Apache2.4で社内ADのアカウントを利用) 原因 SVN1.8で、デフォルトの転送モードがBulk→Skeltaに変更になった。 http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default 1.8サーバ-1.8クライアントの場合、デフォルトでSke
(SVN merge) 複数のリビジョンを指定してマージ - おはようバッファロー
[svn merge] 複数のリビジョンを指定してマージする方法 会社の人から教えてもらった方法 ・1500と1501の間でおきた変更分をマージする場合 svn merge -r1500:1501 http://svn.hoge.com/trunk . ・1500と1505と1509でおきた変更分をマージする場合 svn merge -c 1500,1505,1509 http://svn.hoge.com/trunk .リビジョンを跨ぎたくない場合は、"-c"が便利かと思います。
Subversion, Git, Mercurialそれぞれでのcherrypicking - wyukawa's diary
つまみ食いとか青田買いといわれるcherrypickingはある特定のコミットをブランチから抜き出して別のブランチに反映させるというものです。 Subversion, Git, Mercuriaそれぞれのやり方を調べてみました。 まずSubversionいってみましょう。 準備 $ svnadmin create repos $ svn checkout file:///tmp/repos work Checked out revision 0. $ cd work/ $ svn mkdir tags branches trunk A tags A branches A trunk $ svn commit -m "add initial dir" Adding branches Adding tags Adding trunk Committed revision 1.trunkの直下に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ある日突然MacからGitHubのプライベートリポジトリに対してpullができなくなりました | クロジカ
マージでの Tree conflict 解消方法メモ - Qiita