14
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Gitを何故使うのか

Last updated at Posted at 2018-04-07

Gitを使う理由としては、
・チーム開発でも自分個人のリポジトリが持てる
・ブランチを気軽に作ることが出来る
ところでしょうか。

そもそも、ソースコードバージョン管理ツールを使わない場合

まずは、SubversionやGitのようなソースコードバージョン管理ツールを使わない場合、
ファイルのバックアップで行うことになりますが、得てしてこんなこと(惨事)にもなります。

hello.20180215.c
hello.c.bak
hello.c.bak2
hello.c.bak.bak
hello.c.org
backup_20180325/hello.c

ソースコードバージョン管理ツールを使う

Subversion(svn)やGitなどのツールを使えば、

  • ファイルをそのままの名前で履歴管理してくれる
  • そのバージョンの説明(コミットコメント)も記録出来る
  • バージョン間の比較も簡単
  • 過去のバージョンに戻すことも簡単

なので、ソフトウェア開発において必須のツールと言えます。

チーム開発でも自分個人のリポジトリが持てる

リポジトリがチームのものになる

チーム開発となると、リポジトリ(バージョン管理のデータベース)が共有されるので、Subversionでは気軽なコミットが出来なくなります。

ビルドが通らない、動かないような適当なタイミングでコミットしてしまうと、チームに迷惑が掛かってしまうので、
レビューを実施し、ビルドも通り、きちんと動作する状態のソースコードしかコミット出来ません。
そうなると、ローカルの開発は、

hello.20180215.c
hello.c.bak
hello.c.bak2
hello.c.bak.bak
hello.c.org
backup_20180325/hello.c

に戻ってしまいます。

ローカルにリポジトリを作ってみる

では、対策として、ローカルにSubversionのリポジトリを新たに作成して、そこにソースコードをコミットしてみます。
こうすれば、チーム開発でも気軽なコミットが(ローカル限定ですが)出来るようになります。

ただ、面倒くさいです。
こんな作業を都度やらないといけないです。

  • 元のリポジトリからチェックアウトしたファイルを、ローカルのリポジトリにコピーしてコミットする
  • ローカルで開発したソースコードを、元のリポジトリにコピーしてコミットする
  • ローカルでのコミット履歴を元のリポジトリには反映したければ、ローカルのコミット単位で元のリポジトリにコミットする。

なかなかやってられないですね。

Git

この、ローカルでリポジトリを作成して、元のリポジトリを取り込む、
そして、ローカルでの作業結果を元のリポジトリに反映するという作業を専用コマンドで簡単に出来るようにしたのがGitです。

clone コマンドで、元の(リモート)リポジトリとリンクするローカルリポジトリを簡単に作れます。
pullやfetchコマンドで、リモートリポジトリのコミットをローカルリポジトリに簡単に取り込めます。
pushコマンドで、ローカルのコミット履歴をそのままリモートリポジトリに反映出来ます。

ローカルでの適当なコミット履歴だとマスターとなるリモートリポジトリに反映出来ない(したくない)、という場合は、
commit --amendやrebaseコマンドで既存のコミットやコミットコメントを奇麗にする、ということも出来ます。

ブランチを気軽に作ることが出来る

Gitはブランチを非常に低コストで作ることが出来ます。
ブランチを作成するだけだと、数十バイト程度のファイルが作成されるだけであり。コミットして初めてそのコミット分"だけ"容量が増えるという、非常に軽量な仕組みとなっています。

Gitではそのブランチを活用することで、

  • 「レビューが通って初めてリポジトリに"コミット"出来る」ようなことは無く、
     作業用のfeatureブランチを作成することで、そこで幾らでもコミットすることが出来る。
     →レビューOKとなった作業ブランチをマスターに取り込む。

  • 開発のある程度の作業単位でブランチを作成することで、他担当者、他作業に影響されない開発が可能。
     →同時並行に複数作業が出来る。

  • 作業ブランチに対して、さらにログ仕込み版ブランチというように、好き放題にブランチを作ることが出来る。

そしてGitHub

Gitの人気に最も貢献しているのが、GitHubでしょう。

チームでリポジトリを共有するにはサーバーが必要です。
社内の共有サーバーが有ればそこでもいいのですが、複数拠点での開発となると面倒です。
GitHubは、その共有リポジトリを預かるサービスです。

作業ブランチのコミットをマスターブランチに取り込む為の申請を出す「プルリクエスト」機能も有名ですね。
作業項目(issue)管理機能も有ります。

まとめ

とにかく、Gitは便利です。

便利なのですが、その独特のコマンドの扱い、考え方が初心者に分かり難いということも有ります。
幾つか記事を紹介します。

サルでもわかるGit入門

こわくない Git

【Git】リモートからの取得とリモートへの反映で行っていること(fetch,pull,push)

14
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?