1: 2011-07-28 (木) 06:33:39 yuji ソース 現: 2020-12-26 (土) 15:07:53 yuji ソース
Deleted an attach file: b14.png at 2024-11-07 (木) 10:59:56, Deleted an attach file: b13.png at 2024-11-07 (木) 11:00:06, Deleted an attach file: b12.png at 2024-11-07 (木) 11:00:08, Deleted an attach file: b11.png at 2024-11-07 (木) 11:00:11, Deleted an attach file: b10.png at 2024-11-07 (木) 11:00:13, Deleted an attach file: b9.png at 2024-11-07 (木) 11:00:16, Deleted an attach file: b8.png at 2024-11-07 (木) 11:00:19, Deleted an attach file: b7.png at 2024-11-07 (木) 11:00:22, Deleted an attach file: b6.png at 2024-11-07 (木) 11:00:24, Deleted an attach file: b5.png at 2024-11-07 (木) 11:00:26, Deleted an attach file: b4.png at 2024-11-07 (木) 11:00:28, Deleted an attach file: b3.png at 2024-11-07 (木) 11:01:23, Deleted an attach file: b2.png at 2024-11-07 (木) 11:01:25, Deleted an attach file: b1.png at 2024-11-07 (木) 11:01:28, Deleted an attach file: 共有リポジトリの作成と運用_流れ.png at 2024-11-07 (木) 11:01:33, Deleted an attach file: commit.png at 2024-11-07 (木) 11:01:40, Deleted an attach file: clone.png at 2024-11-07 (木) 11:01:43, Deleted an attach file: pull2.png at 2024-11-07 (木) 11:01:46, Deleted an attach file: fetch.png at 2024-11-07 (木) 11:01:49, Deleted an attach file: merge1.png at 2024-11-07 (木) 11:01:51, Deleted an attach file: merge2.png at 2024-11-07 (木) 11:01:53, Deleted an attach file: merge3.png at 2024-11-07 (木) 11:01:55
Line 1: Line 1:
*gitとは， [#q7c3fbd0] *gitとは， [#q7c3fbd0]
-subversionに代わる新しいバージョン管理システムということで，gitだ。。~ +[[Subversion>../subversion]] に代わる新しいバージョン管理システムということで，Git（[[Linusは「ギット」と発音している>https://youtu.be/4XpnKHJAok8]]）。~ 
-Androidもgitで管理されている。というよりも，Linuxカーネルの管理を目的としてLinus Torvaldsが開発したものだそうだ :)+AndroidもGitで管理されているらしい。というよりも，GitはLinuxカーネルの管理を目的としてLinus Torvalds氏が開発したものだそうだ :)
-たしかにLinuxカーネルの開発では，開発している人たちがLinux Kernel Mailing Listにパッチを投稿して，それをソースに反映させるという開発スタイル。もともと別のバージョン管理システムを使ってたはずなんだけど，なんかの問題でgitを開発したのかな・・・ +Linusはトランスメタ時代にCVSを使えと言われて，その時にCVSを憎むほど嫌いになったらしい。 [[Subversion>../Subversion]] に対しては，史上最大の無意味なプロジェクトであると思っていると言っている。SubversionがCVSの改良というスタンスで開発された訳が，その理由になっている。
-ということで，Linuxカーネルではスゴイ量のソースコード，変更点の抽出やリポジトリ操作があるんだろうから，性能は折り紙付きかな。+
-subversionと何が違うのかというと，大きく違うところは分散レポジトリを使えるということらしい。~ +''集中型バージョン管理システムとの違い''~ 
-分散レポジトリってなにかがよくわからないんだが，ファイルを管理しているデータベースの格納先を中央の1箇所ではなく，いろいろな所に持てるということだと思う。+従来の集中型バージョン管理システム（CVSやSubversion）とGitの違いは，Gitが分散型であるということ。
-gitでの作業フローは，+SubversionとGitと比較してみる。
--中央リポジトリからコピーする +** Subversionでの管理方法 [#te10487c] 
--コピーしたリポジトリを編集し，コンテンツの修正，追加，削除を行う +#ref(svn.png,,50%) 
--ローカルへコミットする +''Subversion''では中央リジトリが1つあって，各ユーザーはリポジトリ((リポジトリとは直訳すると貯蔵庫，倉庫といった意味のようだ。コンピューターだとデータを保管・集積する場所として使われるが，バージョン管理システムでのリポジトリは，それによって管理されたファイル群を指している。))からチェックアウトを行い，作業コピーを取得する。~
--中央リポジトリへ変更内容を反映させる+
-になる。+作業コピーで必要な修正を行った後，修正内容をコミットとしてリポジトリへ反映する。~ 
 +またリポジトリからの修正を取り込むために，アップデートを行ったりする。~
-実際のリポジトリへのアクセスには， +このように常に管理対象のリポジトリが1つなので，特に操作に戸惑うことはない。~
--ローカル +
--WebDAV +
--Git独自プロトコル +
--rsync +
--ssh +
-でアクセスできるようだ。+
-Linusは，トランスメタ時代にCVSを使えと言われて，その時にCVSを憎むほど嫌いになったらしい。Subversionに対しては，史上最大の無意味なプロジェクトであると思っているとの事。SubversionがCVSの改良というスタンスで開発された訳が，その理由になっている :-D+重要なのは，''コミットという操作が共用リポジトリへ反映される''ということなのだが，このことは，''完全には機能しない途中段階のコードは，一切コミットできない''ことを意味するとも言える。~
-**インストール [#e0bea0ae] +** Gitでの管理方法 [#ba998ff3] 
- # yum install git +#ref(git.png,,50%) 
-でインストールした。+これに対してGitでは複数のリポジトリを使用する。~
-**設定 [#i8a8679b] +リモートリポジトリ((Subversionで言うところの中央リポジトリ。))から，クローンという作業でリポジトリの複製（ローカルリポジトリ）を作成する。~
-git configコマンドはで，gitの環境設定ファイルを編集する。 +
-gitの環境設定ファイルは，環境に応じ3つの場所に置かれる。 +
-|設定ファイルの場所|意味|git configのオプション|h +
-|/etc/gitconfig|システム上の全てのユーザとリポジトリ|--system| +
-|～/.gitconfig|各ユーザ用|--global| +
-|.git/config|現在管理中の，Gitリポジトリ|付けない| +
-普通は，--globalを使って設定すればいい気がする。 +
- $ git config --global user.name "Yuji Ueno"            # ユーザ名 +
- $ git config --global user.email yuji@yeno.homeip.net  # メールアドレス +
- $ git config --global color.ui auto                    # 出力を見やすくする +
- $ git config --list +
- color.ui=auto +
- user.name=Yuji Ueno +
- user.email=yuji@yeno.homeip.net+
-**使い方 [#h058b63f] +修正は複製したローカルリポジトリに対して行って，リモートリポジトリへ反映するにはコミットではなくプッシュという操作を行う。~ 
-***作業領域をgitで管理対象にする [#ifb5a1e6] +コミットという操作もあるが，それはローカルリポジトリを対象とした操作のことになる。~
-hogehoheディレクトリ以下をgitで管理する。 +
- $ cd hohehoge +
- $ git init +
-こうすると，hogehogeディレクトリに「.git」というディレクトリが作られ，このディレクトリがリポジトリになる。((個人用))+
-この時だと，まだhogehogeにあるファイルはバージョン管理されていない状態。~ +この仕組みにより，ファイルを管理している格納先を中央の1箇所ではなく，いろいろな所に持てることになる。~
-git statusコマンドでそれが確認できる。トラックしていないファイルって表示される。~ +
- $ git add . +
-でトラックするようにする。addコマンドはいろいろな意味があって，新しいファイルのトラック開始・ファイル衝突時のマージなどのマーク付けなんかで使用するみたいだ。+
-その後，まだリポジトリに変更を確定してないので，コミットする。 +Linuxカーネルの開発のはじめの頃は，開発している多くの人たちがLinux Kernel Mailing Listにパッチを投稿して，それをソースに反映させるという開発スタイルだったようだ。~ 
- $ git commit -m "最初のコミット" +これでは作業が大変だということで，あるバージョン管理システムを使ってみたのだが機能に問題があってGitを開発したらしい。~
-これで，コミットされる。+
-***普段の流れ [#hddb2a26] +ということで，Linuxカーネルではすごい量のソースコード・変更点の抽出・リポジトリ操作なんかが日々あるわけで，これらの管理が問題なく行えているのでGitの性能は折り紙付きなわけです。~
-gitを使った流れは，下記のような感じになる。 +
-+ファイルを編集，新規作成 +
-+git statusで変更状況を確認 +
-+git diffで変更箇所を確認 +
-+編集作業が終わったらgit add ファイル名，またはgit add -uで変更ファイルを記録する指定をする。 +
-+git commitでリポジトリに変更を登録（git commit -a "説明・・・"）+
- $ git status +同じバージョン管理システムでも，中央集権型と分散型では作業手番が異なっていて，同じような操作名（例：コミット）でも，違った動作になったりするので時々混乱する。~
- # On branch master +
- nothing to commit (working directory clean) +
-変更したものがない場合は，statusコマンドを使うと，このような出力が返ってくる。+
-***gitに登録させたくないファイル [#t4285e5b] +Gitを使った作業フローとしては，~ 
-gitに登録させたくない場合のファイル指定は，無視させるファイルを.gitignoreファイルに指定することが出来る。 +- ''リモートリポジトリからコピーする''~ 
-.gitignoreの内容を， +リモートリポジトリは専用のサーバに配置して，複数人で共有するためのリポジトリの事。~ 
- *~ +そこから，ローカルリポジトリ（ユーザ一人ひとりが作業を行うために，自分の手元のマシン上に配置するリポジトリ）にファイルをコピーする。~ 
-のようにすると，file.txt~とかいうファイルを無視するようになる。+このローカルリポジトリから必要なファイルを，ワーキングディレクトリ（作業をする）に配置しておく。~ 
 +- ワーキングディレクトリの''ファイルを編集し，コンテンツの修正・追加・削除などを行う''。~ 
 +- ''ローカルリポジトリへコミットする''~ 
 +普段の作業はローカルリポジトリを使って，全て手元のマシン上でファイルの変更等を管理する。~ 
 +- ''リモートリポジトリへ変更内容を反映させる''~ 
 +ローカルリポジトリでの更新された内容を，リモートリポジトリに反映させる。~ 
 +これにより，共有するファイル類を更新することができる。~
-***共有レポジトリの作成と運用 [#u8c9db25] +のように行う。~
-複数の人で共有するリポジトリがあると便利。 +
- $ mkdir /var/www/git/hogehoge.git +
- $ cd /var/www/git/hogehoge.git +
- $ git init --bare +
-これで，/var/www/git/hogehoge.gitという共有用リポジトリが出来た。+
-前に作った個人用レポジトリ設定を共有リポジトリに反映させる。 +** Gitの良い点 [#x47abe64] 
- $ git push /var/www/git/hogehoge.git master +例えば「ある使用ライブラリを1.xから2.xにバージョンアップする」という作業を考えてみます。~
-これで，共有リポジトリに登録できたんで，複数人で共同作業が行えるようになった。+
-コピーを持ってくるには， +作業タスクは，以下の様な感じになります。~ 
- $ git clone /var/www/git/hogehoge.git hogehoge.new ++ 既存ライブラリの削除（1.xは削除して2.xにするために） 
-とかすればOK。~ ++ 2.xのライブラリをプロジェクトに取り込む 
-svn だとcheckoutに似ているんだけど，gitでは，リポジトリサーバーが保持しているデータを全てコピーする。つまり履歴も含んだ全てが，git cloneとすることで手元に持ってこれる。これは，リポジトリサーバーが万が一壊れちゃっても，どこかに残っているcloneしたデータを戻してやれば復元も可能になる。これまでの履歴ももちろん復元される。~ ++ 1.xから2.xで変更となったAPIの反映 
-このへんが，Subversionとは違うところ。++ Licence表記の変更（必要があれば）
-その後，編集後，例えば，hogehoge.newでfile1.txtを作成後，共有レポジトリに反映させる時には， +これらの変更作業は，それぞれ独立していると考えられる。（それぞれの作業にゴールがある）~
- $ git commit -a "add file1.txt" +
- $ git push origin master +
-これで，共有レポジトリにfile1.txtが追加される。+
-hogehogeディレクトリで，今までの更新を反映させるには， +これをSubversionで管理している場合は，すべての作業が間違いなく完了していないと共有リポジトリにはコミット出来ない。~
- $ cd hogehoge +
- $ git pull /var/www/git/hogehoge.git +
-とすると，hogehogeが，hogehoge.newと結果的には同じになる。+
-これで共同でファイルを編集・更新が出来るようになります。+この事は，以下のことを意味する。~ 
 +- コミット前の動作確認で正しく動作しない場合，自分がどこで間違えたか分からない。~ 
 +- ソフトウェアのコードレビューをする人は，すべての修正作業をまとめてレビューして検証する必要がある。~
-共有リポジトリがある場合の流れ， +これが，もしローカルコミットが出来るとどうなるかというと，~ 
-+git cloneで共有リポジトリからファイルをコピーする ++ 既存ライブラリの削除（1.xは削除して2.xにするために）~ 
-+ファイルを編集，新規作成 +＜コミット1＞ 
-+git commitでリポジトリに変更を登録（git commit -a "説明・・・"） ++ 2.xのライブラリファイルをプロジェクトに取り込む~ 
-+git pushで共有リポジトリを更新 +＜コミット2＞ 
- $git push origin master++ 1.xから2.xで変更となったAPIの反映~ 
 +＜コミット3＞ 
 ++ Licence表記の変更（必要があれば）~ 
 +＜コミット4＞
-***githubを使う [#vcd63cc6] +それぞれの作業タスクで，差分を確認してコミットをすることが出来るようになる。~ 
-共有リポジトリは，別のコンピュータやネットワークの外のコンピュータでも同様に使用できる。~ +この段階では共有リポジトリへの反映はしていないため，他の開発者への影響は全くありません。~ 
-cloneやpushやpullといったコマンドは，ネットワークを経由して行われる。通信プロトコルは，いくつかを選択できるようになっている。~ + 
-githubというのは，共有リポジトリを作成して，それをWeb上で共有できるサービスの事をいうようだ。+つまりローカルコミットがない場合と比べて，どのような変化が起こるかと言うと，~ 
 +- コミット前の動作確認で正しく動作しない場合，コミット単位で間違いを探せる~ 
 +差分（diff）あるいは過去コミットのチェックアウトすることで確認できる。~ 
 +- コードレビューをする人は，それぞれのコミット（独立した作業単位）でレビューして検証出来る~ 
 +作業単位でレビューできるので集中することができる。~ 
 + 
 +のようになりSubversionを使った場合の問題が解決しています。~ 
 + 
 +この構造を採用したバージョン管理がGitになる。ここがSubversionに比べてGitが優れている点になると思う。~ 
 + 
 +* Gitの基本 [#he3c66b2] 
 +Gitには管理している領域に4つの領域があります。~ 
 + 
 +手元のPCに存在する''ワークディレクトリ''，''ステージングエリア''，''ローカルリポジトリ''という3つと，ネットワーク越しに存在する''リモートリポジトリ''です。~ 
 +#ref(基本.png,,50%) 
 + 
 +** 履歴を管理するリポジトリ [#lcc1a833] 
 +リポジトリとは，ファイルやディレクトリの状態を記録する場所です。~ 
 +保存された状態は，内容の変更履歴として格納されています。~ 
 +変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで，そのディレクトリ内のファイルやディレクトリの変更履歴を記録することが出来ます。~ 
 +#ref(リポジトリ1.png,70%) 
 + 
 +** リモートリポジトリとローカルリポジトリ [#i3b4cba6] 
 + 
 +Gitのリポジトリには，''リモートリポジトリ''と''ローカルリポジトリ''の2種類があります。~ 
 + 
 +- ''リモートリポジトリ''~ 
 +ファイルが共有できるファイルサーバー等に配置して，複数人でファイルを共有するためのリポジトリ。~ 
 +- ''ローカルリポジトリ''~ 
 +ユーザ一毎の利用のために，自分のPC上に配置するリポジトリ。~ 
 + 
 +リポジトリをリモートとローカルの2種類に分けることで，普段の作業はローカルリポジトリ（''ローカルリポジトリは自分のPCの任意のディレクトリに作成できる。''）を使って全て自分のPC上で行うことが出来ます。~ 
 +自分のローカルリポジトリで作業した内容をみんなと共有するために，''リモートリポジトリ''にファイルをアップロードして共有・公開します。~ 
 +また，''リモートリポジトリ''を通して，他の人の作業内容を取得することが出来ます。~ 
 + 
 +** ワークディレクトリとインデックス [#g4ff3a17] 
 +各個人が実際に作業をしているディレクトリのことを，Gitでは''ワークディレクトリ''とかワークツリー''と言っている。~ 
 + 
 +そして，リポジトリとワークツリーの間には''ステージング''とかインデックスと呼ばれているところがあります。~ 
 +インデックスは，ローカルリポジトリにコミットする準備をするための場所になります。~ 
 +#ref(流れ.png,50%) 
 + 
 +Gitは，コミットを実行した時にワークツリーから直接ローカルリポジトリ内に状態を記録するのでなく，その間に設けられているインデックスの設定された状態を記録するように処理されます。~ 
 +このため，コミットを使ってファイルの状態を記録するためには，まずインデックスにファイルを登録する必要があります。~ 
 + 
 +このようにインデックスを間に入れることで，ワークツリー内の必要ないファイルを含めずにコミットを行ったり，ファイルの一部の変更だけをインデックスに登録してコミットすることが出来るようになります。~ 
 + 
 +* Gitのインストール [#fc2560c5] 
 +PCに[[Gitをインストール>./Gitのインストール]]する。~ 
 +- 
 + 
 +* Gitの使い方 [#f6b157bb] 
 +[[Gitの使い方>./Gitの使い方]]について。~ 
 + 
 +* Gitで扱えるリモートリポジトリのタイプとアクセス方法 [#waa5b231] 
 +[[リモートリポジトリのタイプとアクセス方法>./Gitで扱えるリモートリポジトリのタイプとアクセス方法]]。 
 + 
 +* リモートリポジトリ（共有リポジトリ）の作成と運用 [#oa215624] 
 +[[リモートリポジトリ（共有リポジトリ）の作成と運用の仕方>./共有リポジトリの作成と運用]]。 
 + 
 +* GitリポジトリホスティングサービスとGit管理ツール [#vdf1f1da] 
 +[[リポジトリホスティングサービスとGit管理ツール>./GitリポジトリホスティングサービスとGit管理ツール]]について。~
  • 開発/バージョン管理システム/git のバックアップ一覧
  • 開発/バージョン管理システム/git のバックアップ差分(No. All)
    • 1: 2011-07-28 (木) 06:33:39 yuji
    • 現: 2020-12-26 (土) 15:07:53 yuji
      • Deleted an attach file: b14.png at 2024-11-07 (木) 10:59:56, Deleted an attach file: b13.png at 2024-11-07 (木) 11:00:06, Deleted an attach file: b12.png at 2024-11-07 (木) 11:00:08, Deleted an attach file: b11.png at 2024-11-07 (木) 11:00:11, Deleted an attach file: b10.png at 2024-11-07 (木) 11:00:13, Deleted an attach file: b9.png at 2024-11-07 (木) 11:00:16, Deleted an attach file: b8.png at 2024-11-07 (木) 11:00:19, Deleted an attach file: b7.png at 2024-11-07 (木) 11:00:22, Deleted an attach file: b6.png at 2024-11-07 (木) 11:00:24, Deleted an attach file: b5.png at 2024-11-07 (木) 11:00:26, Deleted an attach file: b4.png at 2024-11-07 (木) 11:00:28, Deleted an attach file: b3.png at 2024-11-07 (木) 11:01:23, Deleted an attach file: b2.png at 2024-11-07 (木) 11:01:25, Deleted an attach file: b1.png at 2024-11-07 (木) 11:01:28, Deleted an attach file: 共有リポジトリの作成と運用_流れ.png at 2024-11-07 (木) 11:01:33, Deleted an attach file: commit.png at 2024-11-07 (木) 11:01:40, Deleted an attach file: clone.png at 2024-11-07 (木) 11:01:43, Deleted an attach file: pull2.png at 2024-11-07 (木) 11:01:46, Deleted an attach file: fetch.png at 2024-11-07 (木) 11:01:49, Deleted an attach file: merge1.png at 2024-11-07 (木) 11:01:51, Deleted an attach file: merge2.png at 2024-11-07 (木) 11:01:53, Deleted an attach file: merge3.png at 2024-11-07 (木) 11:01:55
トップ   差分 バックアップ 複製 名前変更 リロード   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ   最新ページのRSS 1.0 最新ページのRSS 2.0 最新ページのRSS Atom
Counter: 769, today: 1, yesterday: 0
ページ別名: 未設定
ページ作成: yuji
サイト管理: yuji