【エンジニアの道は果てしない】いまさら聞けないGit、未来と過去を行き来するパラレルワールド

すうち

2023年1月22日 23:57

こんにちは。すうちです。

今回のメインはGitの話ですが、後半は少し脱線したnoteのパラレルワールド感について思った話です。

はじめに

Gitとは

ソフトウェアのバージョン管理に用いるツールです。

元はオープンソースのコード管理に開発された経緯からソフトウェアのバージョン管理に多く使われていますが、最近はWEBデザイナやライタの方がデザインやテキストの管理に使うケースもあるようです。

やろうと思えば、noteに投稿するテキストのバージョン管理などもできます。

よく誤解されがちですが、GitHubはGitとは別物でオープンソース開発や個人で開発したものをWEB上に公開・共有できるサービスです。

GitHubに公開したものはプライベートリポジトリ（非公開設定）にしない限り、全世界の誰でもアクセスできます。

なぜGit（バージョン管理）が必要か

ソフトウェア開発は、通常複数名で開発します。そうなると同じファイルを共有したり修正するためバージョン管理を正しく行う必要があります（どれが最新か分からなくなったり、修正が混在して最新版を確定できない問題を防ぐ）。

またソフトウェア開発は修正のタイミングで問題が発生して動かなくなるトラブルもあるので、後述のブランチという単位で先行開発とテスト済み（動作保証済）のコードを分けて管理します。

これにより問題発生時はバージョン履歴に沿って動作してたソフトウェア（過去）に戻したり、現行に機能追加した別バージョン（未来）を先行開発することができます。

つまりGitでソフトウェアのバージョン管理をすることで、未来や過去を簡単に行き来することができます。

ちなみに、バージョン管理はGit以外にもCVSやSubversionなどもあります。

昔Git以外のツールも使ったことありますが、処理が重かったりサーバー側に繋がないとできる事が限られる等、使いにくかった記憶があります。

それに比べてGitは分散型システムでバージョン管理はローカルに情報あるので、操作に慣れれば動作も軽くてよいという特徴があります。

Git用語（概念）

リポジトリ
プロジェクト単位でまとめられたコード一式を指すことが多いです。大規模な開発ではプロジェクト内の機能やサービス単位で分ける場合もあります。

ブランチ
リポジトリ配下で開発工程に応じてプログラムを分けて管理したい場合に使います。

例えば、ソースのベースを管理するmaster。テスト済みの分岐はrelease。次のリリース予定の新機能（例 :ユーザ課金など）はdevelopで分岐して管理します。

developブランチの先行開発は、通常テスト後にmasterブランチにマージ（統合）されます。※場合によってはボツになることも…

またreleaseで不具合が発生して、問題解析や修正後のテスト用にブランチ（hotfix）がある場合もありますが、この辺は会社ルールやプロジェクト単位で実際は様々かと思います。

コミット
新機能を追加したり、コード修正後にそれらを確定する（バージョン履歴に記録する）ことです。

プッシュ
Gitのバージョン管理はコミット時点でローカルに反映されますが、リモート側には記録されません。プロジェクトのメンバに共有するにはローカルの変更をリモートにプッシュ（記録）する必要があります。

Gitの使い方（よく使うコマンド）

(a）git管理のリポジトリをリモートからコピーする場合

git clone
リモートからgitのリポジトリをコピー(クローン)するコマンド。

$ git clone https://Hoge.com/xxx.git # [cloneするアドレス]
Cloning into 'xxx'...
remote: Enumerating objects: 23, done.
remote: Counting objects: 100% (23/23), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 23 (delta 11), reused 22 (delta 10), pack-reused 0
Receiving objects: 100% (23/23), 16.16 KiB | 16.16 MiB/s, done.
Resolving deltas: 100% (11/11), done.

(b）ローカルのフォルダ配下をgit管理にする場合

ここからは、以下フォルダ構成でコマンドを使った例です。

D:.
└─note
        account_A.txt
        account_B.txt
        account_C.txt
        README.md

git init
フォルダ配下のソースコードや関連ファイルをgit管理におく初期化コマンド。

$ git init
Initialized empty Git repository in D:/note/.git/

git add
新しいファイル等をgit管理に追加するコマンド。

#　git add [file1] .. [fineN] 個別指定も可
$ git add .　#  .は全ファイル追加

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md
        new file:   account_A.txt
        new file:   account_B.txt
        new file:   account_C.txt

git commit
ファイルの修正をgitのバージョン履歴に記録するコマンド。

$ git commit -a
[master (root-commit) 74a147b] 1st commit on note
 4 files changed, 16 insertions(+)
 create mode 100644 README.md
 create mode 100644 account_A.txt
 create mode 100644 account_B.txt
 create mode 100644 account_C.txt

git push
ローカルのバージョン履歴の修正をリモートに反映するコマンド。

# リモートの登録
$ git remote add origin [リモートのアドレス]

# リモートに修正反映
$ git push origin master

git branch
現存のブランチ表示や新しいブランチ生成のコマンド。

# ブランチ表示
$ git branch
* master

# A_historyブランチ生成（masterから分岐）
$ git branch A_history master
$ git branch
  A_history
* master

git checkout
ブランチ切替えコマンド。-bでcheckoutと同時にブランチ生成も可能。

#　A_historyブランチへ移動
$ git checkout A_history
Switched to branch 'A_history'

#　C_historyブランチ生成＆移動
$ git checkout -b C_history master
Switched to a new branch 'C_history'

$ git branch
  A_history
* C_history
  master

[例：ファイル修正]
ここで C_historyブランチにてaccount_C.txtを修正しコミット。

# 修正前
$ cat account_C.txt
Follow:


Contents:
kiji1

# 修正後
$ cat account_C.txt
Follow:
account_A
account_B

Contents:
kiji1
kiji2
kiji3
kiji4
kiji5
kiji6

$ git commit -a
[C_history 0799dfe] Modified account_C
 1 file changed, 7 insertions(+), 1 deletion(-)

git merge
ブランチの変更履歴を別ブランチに反映(マージ)するコマンド。

# masterブランチへ移動
$ git checkout master
Switched to branch 'master'

$ git merge C_history
Updating bf98b6d..0799dfe
Fast-forward
 account_C.txt | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

git tag
変更履歴にリリースバージョンなどの目印(タグ)を付けるコマンド。

# git tag [tag name] [commit ID]
$ git tag Renew-0122 0799df

git log
checkoutしたブランチの変更履歴を表示するコマンド。

$ git log --oneline
0799dfe (HEAD -> master, tag: Renew-0122, C_history) Modified account_C
bf98b6d (A_history) Modified account_A
c1bf353 1st commit on note

この例では、account_A.txt とaccount_C.txtの更新履歴がmasterブランチに反映されていることがわかります。

noteで感じるパラレルワールド感

ここからは脱線して、以下noteを続けてて思うことです。

noteの世界は色んなクリエイターの方がいて、その数５００万人とも言われてます。それぞれのアカウントは意図的に探したりnoteに表示されない限り知ることは難しいです。

以前アカウントログアウト状態でnoteを見たらいつもと全然違う世界（知らないクリエータの方や普段目にしない投稿）が広がってました。

（ここからは推測です…）noteアカウントにログインした状態は、noteのアルゴリズムによってフォローしてる方の投稿や自分がスキした履歴によるおすすめを優先的に表示する仕組みと想像します。

つまり、自分が観ているnoteの世界と他のアカウントから見る世界（表示内容など）は全然違うんだろうな、ということです。

スキやフォローでその方と繋がると自分のnoteにも表示される訳ですが、その時に今まで知らなかった（でもnoteに並行して存在していた）世界が繋がる感があるなと思いました。

私もそれなりフォローしている方が増えてきましたが、たまに何かのきっかけで思考が似た方や興味ある記事を書かれている方を知って「noteにこんな方がいたのか…」と驚くこともあります。

前述のGitの話に例えると、noteでフォローすることは

並行して存在していたブランチがある時、自分のブランチにマージされる

イメージを持ちました。

少し特異な視点かもしれませんが、わかる人には伝わるかもと思うことにします。。。

最後に

今回は最初Gitの話のみ書く予定でした。途中でGitのブランチってnoteのつながり方のイメージに近い気がしたので例に挙げましたが、余計わかりにくくなったかもしれません…笑

最後まで読んで頂き、ありがとうございました。

この記事が気に入ったらサポートをしてみませんか？