Gitとは
分散型バージョン管理システム。名前の通り、リポジトリが分散している＝個人個人が手元にそれぞれのリポジトリを持っている。
開発による個々人のリポジトリの変更内容を、共有リポジトリという形で複数人と共有できる。
Git学習法
Git入門：Git初学習者のための効率的な学習方法を考えてみた
本記事は，Git Advent Calendar 2014の13日目に投稿させて頂いた記事です．Gitの使い方がわからない人向けの記事です。 モチベーション 自分を成長させながらいかに効率的に技術を伝承するかが自分の中で課題になっており模索...
blog.takanabe.tokyo
GitHub - takanabe/introduction-to-git: https://github.com/Shinpeim/introduction-to-gitに各章で利用するレポジトリを追加したものです。
に各章で利用するレポジトリを追加したものです。 - takanabe/introduction-to-git
github.com
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
ようこそ、サル先生のGit入門へ。Gitをつかってバージョン管理ができるようになるために一緒に勉強していきましょう！
backlog.com
Gitにおける3つの領域
作業ディレクトリ (ワーキングディレクトリ)
- 現在作業しているファイルが存在する場所。
- ファイルに変更を加えると、その変更は作業ディレクトリに反映される
ステージングエリア (インデックス)
- 変更をコミットする前に、変更を一時的に保持する場所
git add <file>を実行することで、作業ディレクトリの変更をステージングエリアに追加（ステージ）する
リポジトリ
- プロジェクトの歴史（コミットされた変更）が保存される場所。
git commitを実行すると、ステージングエリアの変更がリポジトリに永続的に保存される
コマンドとその動作:
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 developmentgit fetch
- リモートリポジトリの最新の履歴を取得し、ローカルの追跡ブランチに反映するが、現在の作業ブランチには自動的にマージされない（ローカルの作業ディレクトリのファイルは変更されない）。
- 単にリモートリポジトリの内容を確認したいだけの時に使う
—set-upstream-to（短縮形： -u オプション）
- 特定のブランチに対するデフォルトのリモート追跡ブランチを設定する
- このコマンドは feature ブランチを origin/feature ブランチに追跡させるように設定する。これにより、git pull や git push を実行した際に、デフォルトで origin/feature が使用されるようになる。
- リモートブランチが存在しない場合や新しくブランチを作成したばかりの場合など、明示的な関連付けが必要な時に便利
ShellScript
git branch --set-upstream-to=origin/feature featuregit reset —hard <commit id>
- 今選択しているブランチをcommit idまで戻し、作業ディレクトリ内にその時の状態を復元する
git push
- これまでのコミット内容を共有リポジトリに送る
- 手元のリポジトリでのブランチの名前とリモートリポジトリのブランチ名が同一の場合は、＜手元のブランチ＞を省略できる
ShellScript
$ git push <リモートリポジトリの名前＞ ＜手元のブランチ＞:＜ブランチの名前＞
$ git push origin hotfix:hotfix
$ git push <リモートリポジトリの名前＞ ＜ブランチの名前＞
$ git push origin hotfixgit pull
- 共有リポジトリから最新内容を持ってくる
- fetchしてmerge という一連の動作を自動でやる
その他、gitコマンド一覧とoh-my-zshでのgitコマンドのaliasはこちら。
gitコマンドのショートカットによる時短狙い。
A successful Git Branching model
A successful Git branching model を翻訳しました
Vincent Driessenさんの " A successful Git branching model " を翻訳しました。 元記事はこちら： （翻訳の公開と...
keijinsonyaban.blogspot.com
リリースブランチ
- ブランチの頭にrelease-をつける
- 普段の開発はdevelopブランチ上で行なっているため、リリース可能な状態が近づいてからrelaese branchを作成し、リリースに向けた最終的なバグ修正などの開発を行う
- 最終的にrelease branchがリリース可能な状態になったらmasterブランチにマージして、できたマージコミットに対してリリース番号のタグを追加する
hotfix
- すでにリリースしてしまったものに不具合が見つかったときにそれを緊急で修正しなければならないときには、master ブランチから hotfix ブランチを切って、ここで修正した内容を master ブランチに merge する。これで、開発中のものを急いでリリースせずに、緊急の対応だけは先にリリース版に組み込むことができる。
コメント