1: 2011-07-28 (木) 06:33:39 yuji ソース 現: 2020-12-26 (土) 16: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つであるため操作に戸惑うことは少ないです。~
-になる。+重要なのは，''コミットという操作が共用リポジトリへ反映される''ということは，''完全には機能しない途中段階のコードは一切コミットできない''ことを意味するとも言えます。~
-実際のリポジトリへのアクセスには， +** Gitでの管理方法 [#ba998ff3] 
--ローカル +#ref(git.png,,50%) 
--WebDAV +これに対してGitでは，複数のリポジトリを使用します。~ 
--Git独自プロトコル +リモートリポジトリ((Subversionで言うところの中央リポジトリ。))から，クローンと言う作業でリポジトリの複製（ローカルリポジトリ）を作成します。~ 
--rsync +修正は複製したローカルリポジトリに対して行い，リモートリポジトリへの反映にはコミットではなくプッシュという操作を行います。~ 
--ssh +コミットという操作もありますが，それはローカルリポジトリを対象とした操作のことになります。~
-でアクセスできるようだ。+
-Linusは，トランスメタ時代にCVSを使えと言われて，その時にCVSを憎むほど嫌いになったらしい。Subversionに対しては，史上最大の無意味なプロジェクトであると思っているとの事。SubversionがCVSの改良というスタンスで開発された訳が，その理由になっている :-D+この仕組みにより，ファイルを管理しているデータベースの格納先を中央の1箇所ではなく，いろいろな所に持てることになります。~
-**インストール [#e0bea0ae] +Linuxカーネルの開発では，開発している多くの人たちがLinux Kernel Mailing Listにパッチを投稿して，それをソースに反映させるという開発スタイルでした。~ 
- # yum install git +これでは作業が大変なのであるバージョン管理システムを使ってたのだが，機能に問題があってGitを開発したらしい。ということで，Linuxカーネルではスゴイ量のソースコード，変更点の抽出やリポジトリ操作があるわけで，これらの管理を行えているので性能は折り紙付きなわけです。~
-でインストールした。+
-**設定 [#i8a8679b] +このように，同じバージョン管理システムでも中央集権型と分散型では作業手番が異なりますし，同じ操作名（例えばコミット）でも異なる動作になったりするので，時々混乱します。~
-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を使った作業フローとしては，~ 
-***作業領域をgitで管理対象にする [#ifb5a1e6] +- ''リモートリポジトリからコピーする''~ 
-hogehoheディレクトリ以下をgitで管理する。 +リモートリポジトリは専用のサーバに配置して，複数人で共有するためのリポジトリの事。~ 
- $ cd hohehoge +そこから，ローカルリポジトリ（ユーザ一人ひとりが利用するために，自分の手元のマシン上に配置するリポジトリ）に持ってくる。~ 
- $ git init +このローカルリポジトリから必要なファイルをワーキングディレクトリに配置しておく。~ 
-こうすると，hogehogeディレクトリに「.git」というディレクトリが作られ，このディレクトリがリポジトリになる。((個人用))+- ワーキングディレクトリの''ファイルを編集し，コンテンツの修正，追加，削除などを行う''。~ 
 +- ''ローカルリポジトリへコミットする''~ 
 +普段の作業はローカルリポジトリを使って，全て手元のマシン上でファイルの変更等を管理します。~ 
 +- ''リモートリポジトリへ変更内容を反映させる''~ 
 +ローカルリポジトリでの更新された内容を，リモートリポジトリに反映させます。~ 
 +これにより，共有するファイルを更新することができる。~
-この時だと，まだhogehogeにあるファイルはバージョン管理されていない状態。~ +のように行います。~
-git statusコマンドでそれが確認できる。トラックしていないファイルって表示される。~ +
- $ git add . +
-でトラックするようにする。addコマンドはいろいろな意味があって，新しいファイルのトラック開始・ファイル衝突時のマージなどのマーク付けなんかで使用するみたいだ。+
-その後，まだリポジトリに変更を確定してないので，コミットする。 +** Gitの良い点 [#x47abe64] 
- $ git commit -m "最初のコミット" +例えば，「ある使用しているライブラリを1.xから2.xにバージョンアップする」という作業を考えてみます。~
-これで，コミットされる。+
-***普段の流れ [#hddb2a26] +作業タスクは，以下の様な感じになります。~ 
-gitを使った流れは，下記のような感じになる。 ++ 既存ライブラリの削除（1.xは削除して2.xにするために） 
-+ファイルを編集，新規作成 ++ 2.xのライブラリをプロジェクトに取り込む 
-+git statusで変更状況を確認 ++ 1.xから2.xで変更となったAPIの反映 
-+git diffで変更箇所を確認 ++ Licence表記の変更（必要があれば）
-+編集作業が終わったらgit add ファイル名，またはgit add -uで変更ファイルを記録する指定をする。 +
-+git commitでリポジトリに変更を登録（git commit -a "説明・・・"）+
- $ git status +これらの変更作業は，それぞれ独立していると考えられる。（それぞれの作業にゴールがある）~ 
- # On branch master +これをSubversionで管理している場合は，すべての作業が間違いなく完了していないと共有リポジトリにはコミット出来ない。~
- nothing to commit (working directory clean) +
-変更したものがない場合は，statusコマンドを使うと，このような出力が返ってくる。+
-***gitに登録させたくないファイル [#t4285e5b] +この事は，以下のことを意味する。~ 
-gitに登録させたくない場合のファイル指定は，無視させるファイルを.gitignoreファイルに指定することが出来る。 +- コミット前の動作確認で正しく動作しない場合，自分がどこで間違えたか分からない。~ 
-.gitignoreの内容を， +- ソフトウェアのコードレビューをする人は，すべての修正作業をまとめてレビューして検証する必要がある。~
- *~ +
-のようにすると，file.txt~とかいうファイルを無視するようになる。+
-***共有レポジトリの作成と運用 [#u8c9db25] +これが，もしローカルコミットが出来るとどうなるかというと，~ 
-複数の人で共有するリポジトリがあると便利。 ++ 既存ライブラリの削除（1.xは削除して2.xにするために）~ 
- $ mkdir /var/www/git/hogehoge.git +＜コミット1＞ 
- $ cd /var/www/git/hogehoge.git ++ 2.xのライブラリファイルをプロジェクトに取り込む~ 
- $ git init --bare +＜コミット2＞ 
-これで，/var/www/git/hogehoge.gitという共有用リポジトリが出来た。++ 1.xから2.xで変更となったAPIの反映~ 
 +＜コミット3＞ 
 ++ Licence表記の変更（必要があれば）~ 
 +＜コミット4＞
-前に作った個人用レポジトリ設定を共有リポジトリに反映させる。 +それぞれの作業タスクで，差分を確認してコミットをすることが出来るようになる。~ 
- $ git push /var/www/git/hogehoge.git master +この段階では共有リポジトリへの反映はしていないため，他の開発者への影響は全くありません。~
-これで，共有リポジトリに登録できたんで，複数人で共同作業が行えるようになった。+
-コピーを持ってくるには， +つまりローカルコミットがない場合と比べて，どのような変化が起こるかと言うと，~ 
- $ git clone /var/www/git/hogehoge.git hogehoge.new +- コミット前の動作確認で正しく動作しない場合，コミット単位で間違いを探せる~ 
-とかすればOK。~ +差分（diff）あるいは過去コミットのチェックアウトすることで確認できる。~ 
-svn だとcheckoutに似ているんだけど，gitでは，リポジトリサーバーが保持しているデータを全てコピーする。つまり履歴も含んだ全てが，git cloneとすることで手元に持ってこれる。これは，リポジトリサーバーが万が一壊れちゃっても，どこかに残っているcloneしたデータを戻してやれば復元も可能になる。これまでの履歴ももちろん復元される。~ +- コードレビューをする人は，それぞれのコミット（独立した作業単位）でレビューして検証出来る~ 
-このへんが，Subversionとは違うところ。+作業単位でレビューできるので集中することができる。~
-その後，編集後，例えば，hogehoge.newでfile1.txtを作成後，共有レポジトリに反映させる時には， +のようになり問題が解決しています。~ 
- $ git commit -a "add file1.txt" +この構造を採用したバージョン管理がGitです。ここがSubversionに比べてGitが優れている点になると思います。~
- $ git push origin master +
-これで，共有レポジトリにfile1.txtが追加される。+
-hogehogeディレクトリで，今までの更新を反映させるには， +* Gitの基本 [#he3c66b2] 
- $ cd hogehoge +Gitには，管理している領域に4つの領域があります。~
- $ git pull /var/www/git/hogehoge.git +
-とすると，hogehogeが，hogehoge.newと結果的には同じになる。+
-これで共同でファイルを編集・更新が出来るようになります。+手元のPCに存在する''ワークディレクトリ''，''ステージングエリア''，''ローカルリポジトリ''という3つと，ネットワーク越しに存在する''リモートリポジトリ''です。~ 
 +#ref(基本.png,,50%)
-共有リポジトリがある場合の流れ， +** 履歴を管理するリポジトリ [#lcc1a833] 
-+git cloneで共有リポジトリからファイルをコピーする +リポジトリとは，ファイルやディレクトリの状態を記録する場所です。~ 
-+ファイルを編集，新規作成 +保存された状態は，内容の変更履歴として格納されています。~ 
-+git commitでリポジトリに変更を登録（git commit -a "説明・・・"） +変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで，そのディレクトリ内のファイルやディレクトリの変更履歴を記録することが出来ます。~ 
-+git pushで共有リポジトリを更新 +#ref(リポジトリ1.png,70%)
- $git push origin master+
-***githubを使う [#vcd63cc6] +** リモートリポジトリとローカルリポジトリ [#i3b4cba6] 
-共有リポジトリは，別のコンピュータやネットワークの外のコンピュータでも同様に使用できる。~ + 
-cloneやpushやpullといったコマンドは，ネットワークを経由して行われる。通信プロトコルは，いくつかを選択できるようになっている。~ +Gitのリポジトリには，''リモートリポジトリ''と''ローカルリポジトリ''の2種類があります。~ 
-githubというのは，共有リポジトリを作成して，それをWeb上で共有できるサービスの事をいうようだ。+ 
 +- ''リモートリポジトリ''~ 
 +ファイルが共有できるファイルサーバー等に配置して，複数人でファイルを共有するためのリポジトリ。~ 
 +- ''ローカルリポジトリ''~ 
 +ユーザ一毎の利用のために，自分の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 (土) 16: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: 673, today: 1, yesterday: 1
ページ別名: 未設定
ページ作成: yuji
サイト管理: yuji