git
2015年07月16日
小規模開発でのGit活用方法(3)~リポジトリ~
ローカルリポジトリとリモートリポジトリ
GitにはSubviersionにないものがあります。
それは「ローカルリポジトリ」です。
集中型と呼ばれるSubversionには「中央リポジトリ」のみ存在して
変更するコードのみを保持している状態です。
しかし分散型のGitには必ず作業する場所(マシン、個人、フォルダにかかわらず)
個々の「ローカルリポジトリ」が存在します
むしろ最小単位での作業は「ローカルリポジトリ」だけで作業は完結できます
少人数と言わず一人でも完結したソース管理ができるツールです
今回は少人数での作業を想定しているので
「中央リポジトリ」と同じように作業共有できる「リモートリポジトリ」を準備します
GitにはSubviersionにないものがあります。
それは「ローカルリポジトリ」です。
集中型と呼ばれるSubversionには「中央リポジトリ」のみ存在して
変更するコードのみを保持している状態です。
しかし分散型のGitには必ず作業する場所(マシン、個人、フォルダにかかわらず)
個々の「ローカルリポジトリ」が存在します
むしろ最小単位での作業は「ローカルリポジトリ」だけで作業は完結できます
少人数と言わず一人でも完結したソース管理ができるツールです
今回は少人数での作業を想定しているので
「中央リポジトリ」と同じように作業共有できる「リモートリポジトリ」を準備します
ayuthky_m at 15:46|Permalink│Comments(0)│
2014年12月16日
小規模開発でのGit活用方法(2)~環境整備~
ではGitをつかってみよう
Linux
1)Fedora/CentOS/RetHat
$ yum install git-core
2)Ubuntu/Debian
$ apt-get install git
Windows
Gitライブラリが簡単に入手できるようになった。
Windowsでも以前は導入の手順が困難で避けられていたが現状困ることはなくなった
Atlassian社が提供している無料クライアントツール
MercurialとGit双方使える
Bitbucketとも親和性が高い
(イ) TortoiseGit(https://code.google.com/p/tortoisegit/wiki/Download?tm=2)
TortoiseSubversionに使い慣れていた人に朗報
ソースフォルダで右クリックです
Linux
1)Fedora/CentOS/RetHat
$ yum install git-core
2)Ubuntu/Debian
$ apt-get install git
Windows
- ライブラリ
Gitライブラリが簡単に入手できるようになった。
Windowsでも以前は導入の手順が困難で避けられていたが現状困ることはなくなった
- クライアント
Atlassian社が提供している無料クライアントツール
MercurialとGit双方使える
Bitbucketとも親和性が高い
(イ) TortoiseGit(https://code.google.com/p/tortoisegit/wiki/Download?tm=2)
TortoiseSubversionに使い慣れていた人に朗報
ソースフォルダで右クリックです
ayuthky_m at 13:54|Permalink│Comments(0)│
小規模開発でのGit活用方法(1)~導入検討段階~
会社普及用にGit資料を作ったのでまとめておく
個人的にはGitHubが有名になったあたりからGitって何だと思っていろいろ試行錯誤して
Gitをそれなりに使えるようになってきたので利点など
集中型バージョン管理システムの問題
何かと現場が巨大プロジェクトでSubversion、CVSとか使ったことあるけど。。。
っていう人が多くて「中央リポジトリ」 の呪縛から離れられなった。
これらは「集中型バージョン管理システム」といわれてる
何がだめって全部のリポジトリは巨大すぎるため
1コミットの責任が重過ぎて潜在コミットが貯まる。
そのコミットは個人で管理してるもんだから、あいつ休んでるからコミットできない、治した、
あそこがだめだから治せない、コミットしたらほかの奴が上書きしたとかバグ以前の問題が多発。
それから開放してくれるのがGitとかMercurialとかBazaarとか「分散型バージョン管理システム」
Gitに乗り換えるにあたって
Subversionを使ったことがあるひとが嵌る罠があります
同じ名前のコマンドで大きく働きが違います。
「コミット」
Subversionでコミットっといったら恐れ多くも「中央レポジトリ」に配置するためのコマンド
白昼にすべてをさらされ、ビルドエラーを出すような恥ずかしいことになったら。。。というアレです。
Gitのコミットは編集中ファイル保存レベルの手軽さ。その違いはローカルリポジトリに存在にあります。
ローカルリポジトリについてはのちほど
「ブランチ」
Subversionでは trunkという絶対不可侵の「中央リポジトリ」があり、ここにコミットしたら本流となります。
本流とは別に先行した機能をや、リリース済みバージョンからのバグ修正等を対応する場合ブランチを
作成することになる。Gitでも考え方は一緒ですが、ローカルリポジトリ単位での作成が可能。且つ本流に乗せる前に試すためだけに作ることも可能。
「Index」「ワーキングディレクトリ」「ステージングエリア」
Subversionでは聞きなれない用語がでてきます。
Subversionはコードツリー階層フォルダ毎に「.svn」の管理情報フォルダが存在しますが、
Gitではコードツリー階層のルートディレクトリのみに「.git」の管理情報フォルダが存在します。
「ワーキングディレクトリ」とはファイルがある場所を示しそれを管理情報の「Index」という目録に
「git add」というコマンドで登録します。登録すると管理対象になり「ステージングエリア」という
コミットしてもいい状態になります。
Subversionと違って段階をひとつ多く踏まなければコミットできないのです。ただし中央リポジトリの
敷居の高さに比べたら簡単なものです.。
Gitのいいとこと
Gitではリポジトリを能動的に個人が制御できることです
個人的にはGitHubが有名になったあたりからGitって何だと思っていろいろ試行錯誤して
Gitをそれなりに使えるようになってきたので利点など
集中型バージョン管理システムの問題
何かと現場が巨大プロジェクトでSubversion、CVSとか使ったことあるけど。。。
っていう人が多くて「中央リポジトリ」 の呪縛から離れられなった。
これらは「集中型バージョン管理システム」といわれてる
何がだめって全部のリポジトリは巨大すぎるため
1コミットの責任が重過ぎて潜在コミットが貯まる。
そのコミットは個人で管理してるもんだから、あいつ休んでるからコミットできない、治した、
あそこがだめだから治せない、コミットしたらほかの奴が上書きしたとかバグ以前の問題が多発。
それから開放してくれるのがGitとかMercurialとかBazaarとか「分散型バージョン管理システム」
Gitに乗り換えるにあたって
Subversionを使ったことがあるひとが嵌る罠があります
同じ名前のコマンドで大きく働きが違います。
「コミット」
Subversionでコミットっといったら恐れ多くも「中央レポジトリ」に配置するためのコマンド
白昼にすべてをさらされ、ビルドエラーを出すような恥ずかしいことになったら。。。というアレです。
Gitのコミットは編集中ファイル保存レベルの手軽さ。その違いはローカルリポジトリに存在にあります。
ローカルリポジトリについてはのちほど
「ブランチ」
Subversionでは trunkという絶対不可侵の「中央リポジトリ」があり、ここにコミットしたら本流となります。
本流とは別に先行した機能をや、リリース済みバージョンからのバグ修正等を対応する場合ブランチを
作成することになる。Gitでも考え方は一緒ですが、ローカルリポジトリ単位での作成が可能。且つ本流に乗せる前に試すためだけに作ることも可能。
「Index」「ワーキングディレクトリ」「ステージングエリア」
Subversionでは聞きなれない用語がでてきます。
Subversionはコードツリー階層フォルダ毎に「.svn」の管理情報フォルダが存在しますが、
Gitではコードツリー階層のルートディレクトリのみに「.git」の管理情報フォルダが存在します。
「ワーキングディレクトリ」とはファイルがある場所を示しそれを管理情報の「Index」という目録に
「git add」というコマンドで登録します。登録すると管理対象になり「ステージングエリア」という
コミットしてもいい状態になります。
Subversionと違って段階をひとつ多く踏まなければコミットできないのです。ただし中央リポジトリの
敷居の高さに比べたら簡単なものです.。
Gitのいいとこと
Gitではリポジトリを能動的に個人が制御できることです
ayuthky_m at 11:16|Permalink│Comments(0)│