方言を話すおしゃべり猫型ロボット『ミーア』をリリースしました（こちらをクリック）

【Git】init・status・add・commit・rm・log・merge・branch・checkout・fetch・push・pull

2024.03.29
この記事は約13分で読めます。

Gitとは

分散型バージョン管理システム。名前の通り、リポジトリが分散している＝個人個人が手元にそれぞれのリポジトリを持っている。

開発による個々人のリポジトリの変更内容を、共有リポジトリという形で複数人と共有できる。

Git学習法

https://blog.takanabe.tokyo/2014/12/git%E5%85%A5%E9%96%80git%E5%88%9D%E5%AD%A6%E7%BF%92%E8%80%85%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%8A%B9%E7%8E%87%E7%9A%84%E3%81%AA%E5%AD%A6%E7%BF%92%E6%96%B9%E6%B3%95%E3%82%92%E8%80%83%E3%81%88%E3%81%A6%E3%81%BF%E3%81%9F/

https://github.com/takanabe/introduction-to-git

https://backlog.com/ja/git-tutorial/

Gitにおける3つの領域

作業ディレクトリ (ワーキングディレクトリ)

  • 現在作業しているファイルが存在する場所。
  • ファイルに変更を加えると、その変更は作業ディレクトリに反映される

ステージングエリア (インデックス)

  • 変更をコミットする前に、変更を一時的に保持する場所
  • git add <file>を実行することで、作業ディレクトリの変更をステージングエリアに追加（ステージ）する

リポジトリ

  • プロジェクトの歴史（コミットされた変更）が保存される場所。
  • git commitを実行すると、ステージングエリアの変更がリポジトリに永続的に保存される
出典：https://backlog.com/ja/git-tutorial/intro/04/

コマンドとその動作:

git checkout -- <file>

  • 作業ディレクトリにおける特定のファイルの変更を破棄し、最後のコミット時点の状態に戻す。

git add <file>

  • 特定のファイルの変更をステージングエリアに追加する。

git rm --cached <file>

  • ファイルをステージングエリアから削除するが、作業ディレクトリには残る。
  • さらに、ファイルをgit追跡対象から外すので、このファイルに対する変更を再びコミットに含めたい場合は、git addを使用してファイルを明示的にステージングする必要がある

git restore --staged <file>

  • ファイルをステージングエリアから削除するが、作業ディレクトリには残る。
  • ファイルは依然としてGitによって追跡される。
  • ファイルをコミットする準備ができていないが、変更内容は保持したいときに使う

git rm --cached <file>, git restore --staged <file>どちらのコマンドも、作業ディレクトリにおけるファイルの内容には影響を与えない。

基本コマンド

git init：gitプロジェクト作成

  • 「.git」というディレクトリがプロジェクトのトップディレクトリにできて、git管理下になる
  • .gitディレクトリを消せば、git管理をやめることができる。

git status

  • 変更されたファイルの一覧・ステージングされたファイルの一覧・ブランチの状態が表示される
  • 作用ディレクトリの変更内容をstage, unstageしたい場合に使う
ShellScript
$ git staus
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        new_file.txt

no changes added to commit (use "git add" and/or "git commit -a")

git add

  • git管理下のディレクトリにファイルを作成しただけではgit管理下にならない。
  • git statusと入力すると、Untracked file（gitがトラック（=追跡）していないファイル=未管理のファイル）と表示が出る
ShellScript
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	.DS_Store
#	sample.txt
nothing added to commit but untracked files present (use "git add" to track)
  • 「git add ファイル名」でファイルがgit管理対象になる：git statusで、untrackedからChanges to be committed（ファイルがコミットできるよ）に変わる。
ShellScript
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#	new file:   sample.txt
#

git add .

  • “.” は「現在いるディレクトリ」を指す。
  • git add . はディレクトリを指定しており、「その中身のファイルを全部」と指定したのと同じになる。

git rm

  • Gitリポジトリからファイルやディレクトリを削除するためのコマンド
  • 作業ディレクトリ内で「ファイルの削除」をした時は、その変更を stage するためには git add ではなくて git rm を使う。
  • 作業ディレクトリにファイルが存在する時は、そのファイルを削除する(すでに無い場合はなにもしない)。その後「ファイルを削除したよ」という情報を stageする。

.DS_Store（DS：Desktop Services）

Mac OSが自動的に生成する隠しファイルで、そのフォルダのカスタム属性を保持する。”DS”は”Desktop Services”を表し、このファイルは特定のフォルダに対するビューオプションやアイコンの位置など、ユーザーが設定したフォルダの表示オプションを保存する。

具体的には、フォルダを開いたときのウィンドウのサイズ、表示形式（リストビュー、アイコンビュー、カラムビュー、カバーフロービュー）、アイコンの位置、ソートオプションなど、Finderでのフォルダの表示設定が.DS_Storeファイルに保存される。これにより、フォルダを再度開いたときに同じ状態で表示できるようになる。

→リポジトリで管理する必要のないファイルなので、.gitignoreというファイルをプロジェクトのルートディレクトリに作成して、その中に.DS_Storeを含める。

git commit

  • コミットオブジェクト「stagingされていたファイルの内容 + コミットメッセージ」が作成され、変更内容をリポジトリに反映する。
  • バージョン管理システムで「履歴を残す」というのは、「誰が」「いつ」「何を」したかを残すということ。「誰が」「いつ」の履歴を残すところまでは Gitが面倒を見てくれるが、「何を」したかまでは、機械にはわからない。なので、「何をしたか」をコミットメッセージとして残しておく必要がある。
ShellScript
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   sample.txt
#

git commit —amend

  • 直前のコミットを修正（コミット漏れしたファイルを後から追加・直前のコミットメントを修正）

git log：履歴を見る

  • 誰が、いつ、何を行ったかが記載される
  • コミットメッセージを参考に過去のcommitまで戻れる。
ShellScript
$ git log
commit bfad26e76c5edeXXXXXXXXXXXXXXXX (origin/feature/show-user-sex-place-birthday)
Author: kazu098 <XXXXX.XXXXXX@gmail.com>
Date:   Sat Feb 3 13:40:39 2024 +0900

    UserNotifierを使ってユーザー情報更新

git log —graph：コミットの親子関係を表示

ShellScript
$ git log --graph

* commit f3da9fccf613a61820d901c73936b1fb5044cb7c (HEAD -> feature/integrate-health-kit-api, origin/feature/integrate-health-kit-api)
| Author: kazu098 <kazutaka.yoshinaga@gmail.com>
| Date:   Mon Mar 11 16:32:26 2024 +0900
|
|     fix ヘルスケア連携許可解除dialog
|
* commit acbd39f774f50035a3de305104550595254bd3c3
| Author: kazu098 <kazutaka.yoshinaga@gmail.com>
| Date:   Thu Mar 7 12:16:37 2024 +0900
|
|     manifest.xml修正

git merge

  • マージコミット：マージを行ったときに生まれる特殊なコミット。特殊なというのは、他の通常のコミット（親コミットを1つもつ）と異なり、マージコミットは親コミットを2つ持つという点で。
  • 分岐していないブランチをマージする時には、fast-foward（早送り）マージという手法が自動的に取られるので、fast-forwardしたくない時は—no—ffというオプションをつける。

git branch

  • HEAD：現在選択しているブランチの先頭
  • git branch new_branch_name：新しいブランチをnew_brach_name という名前で作成
  • git checkout branch_name：HEADがbranch_nameになる
  • リモートブランチを選択して作業することはできない→手元（local）に「リモートを追跡するブランチ」を作ることで、そこで行なった変更を追跡元のリモートブランチに反映したり、逆にリモートブランチに行われている変更を追跡ブランチに取り込むことができる。
ShellScript
$ git branch development origin/development
Branch development set up to track remote branch development from origin.

git checkout

  • git branch -b ＜新しく作るブランチの名前＞ ＜分岐元＞とすることで、明示的に「どこからブランチを分岐させるのか」を指定することができる。下記はdevelopmentブランチからfeatureブランチを切っている
ShellScript
$ git checkout -b feature/unify_styles development

git fetch

  • リモートリポジトリの最新の履歴を取得し、ローカルの追跡ブランチに反映するが、現在の作業ブランチには自動的にマージされない（ローカルの作業ディレクトリのファイルは変更されない）。
  • 単にリモートリポジトリの内容を確認したいだけの時に使う

—set-upstream-to（短縮形： -u オプション）

  • 特定のブランチに対するデフォルトのリモート追跡ブランチを設定する
  • このコマンドは feature ブランチを origin/feature ブランチに追跡させるように設定する。これにより、git pull や git push を実行した際に、デフォルトで origin/feature が使用されるようになる。
  • リモートブランチが存在しない場合や新しくブランチを作成したばかりの場合など、明示的な関連付けが必要な時に便利
ShellScript
git branch --set-upstream-to=origin/feature feature

git reset —hard <commit id>

  • 今選択しているブランチをcommit idまで戻し、作業ディレクトリ内にその時の状態を復元する

git push

  • これまでのコミット内容を共有リポジトリに送る
  • 手元のリポジトリでのブランチの名前とリモートリポジトリのブランチ名が同一の場合は、＜手元のブランチ＞を省略できる
ShellScript
$ git push <リモートリポジトリの名前＞ ＜手元のブランチ＞:＜ブランチの名前＞
$ git push origin hotfix:hotfix

$ git push <リモートリポジトリの名前＞ ＜ブランチの名前＞ 
$ git push origin hotfix

git pull

  • 共有リポジトリから最新内容を持ってくる
  • fetchしてmerge という一連の動作を自動でやる

その他、gitコマンド一覧とoh-my-zshでのgitコマンドのaliasはこちら。
gitコマンドのショートカットによる時短狙い。

【Git】oh-my-zshでgitコマンドのalias
Oh My Zshは、Zsh構成を管理するためのオープンソースのコミュニティ主導のフレームワーク。oh-my-zshでのgitコマンドのエイリアスを、特に個人的によく使うものを中心にまとめておく。gitコマンドのショートカットによる時短狙い。
kazulog.fun
2024.07.01

A successful Git Branching model

http://keijinsonyaban.blogspot.com/2010/10/a-successful-git-branching-model.html

出典：https://backlog.com/ja/git-tutorial/stepup/05/

リリースブランチ

  • ブランチの頭にrelease-をつける
  • 普段の開発はdevelopブランチ上で行なっているため、リリース可能な状態が近づいてからrelaese branchを作成し、リリースに向けた最終的なバグ修正などの開発を行う
  • 最終的にrelease branchがリリース可能な状態になったらmasterブランチにマージして、できたマージコミットに対してリリース番号のタグを追加する

hotfix

  • すでにリリースしてしまったものに不具合が見つかったときにそれを緊急で修正しなければならないときには、master ブランチから hotfix ブランチを切って、ここで修正した内容を master ブランチに merge する。これで、開発中のものを急いでリリースせずに、緊急の対応だけは先にリリース版に組み込むことができる。

コメント

タイトルとURLをコピーしました