GitHubを触り始めた超初心者のメモ
めっちゃ触ってる人には蛇足メモ
本当はMacとかLinuxでやるべきかと思うが、残念ながらwindowsなのでごめんなさい。
Mac及びLinuxについては虎視眈々と狙っていきます。
一応e-learningでぼちぼちと勉強しながらですが如何せん難しい
初心者の私がイメージ出来る程度です。
GitHubのイメージ
詳しい事はUdemyで学習中
(多分これを学習するのが一番と思います。)
要は作ったスクリプトのバージョン管理をやり易くするもの。
『誰が』・『いつ』・『何を』変更したのかを管理するシステムの一つ
GitHubの用語について
丸パクリ資料
ただ細かく書いてはいるものの、触り続けないと理解しきれないと思う
特に私の様な初学者で別業務(全く関係ない業態)ではさらに倍率ドン!
用語 | 意味 |
---|---|
リポジトリ (repository) |
履歴管理を行う場所。 (要はGitHubの事) |
リモートリポジトリ (remote repository) |
サーバーにあるリポジトリ。基本はベアリポジトリで運用される。 |
ローカルリポジトリ (local repository) |
自分のPCにあるリポジトリ。基本はノンベアリポジトリで運用される。 (自分のPCの事) |
ベアリポジトリ (bare repository) |
ワークツリーを持たず、チェックアウト、マージができないリポジトリ。 |
ノンベアリポジトリ (non bare repository) |
ワークツリーを持ち、チェックアウト、マージができるリポジトリ。 |
ワークツリー (work tree) |
履歴管理を行いたいファイルがある場所。 |
インデックス (index) |
コミットしたいファイル又はファイルの一部を登録するところ。 |
ステージ (stage) |
ワークツリーからコミットしたいファイル又はファイルの一部をIndexに登録すること。 |
ハンク (hunk) |
変更した一範囲。 |
コミット (commit) |
インデックスに登録してある変更対象をローカルリポジトリに反映すること。 |
リセット (reset) |
コミット前の変更をローカルリポジトリの状態へ戻すこと。 また、特定のコミットまで状態を戻すこと。ただし、ローカルリポジトリに限られる。 |
ヘッド (head) |
作業対象となっているブランチ、コミット。 |
チェックアウト (checkout) |
ヘッドを切り替えること。 過去のコミットを対象にチェックアウトした場合、それをもとにコミットすることはできない。 |
プッシュ (push) |
ローカルリポジトリの変更をリモートリポジトリに反映させること。 |
プル (pull) |
リモートリポジトリの変更をローカルリポジトリに反映させること。フェッチ+マージ |
フェッチ (fetch) |
リモートリポジトリの変更をローカルリポジトリに反映させること。 |
マージ (merge) |
異なるブランチの変更を反映させること。お互いの変更履歴が残る。 |
リベース (rebase) |
異なるブランチの変更を反映させること。変更履歴が片方に集約される。 |
コンフリクト (conflict) |
マージ対象の2ファイルで同じ箇所が変更されており、自動でマージができないこと。 |
ブランチ (branch) |
履歴管理を枝分かれさせてたもの。ブランチを使うこちにより、複数の履歴を並列に管理できる。 |
フォーク (fork) |
リモートリポジトリをコピーしてリモートリポジトリを作成すること。 |
クローン (clone) |
リモートリポジトリをコピーしてローカルリポジトリを作成すること。 |
プルリクエスト (pull request) |
フォークしたリポジトリでの変更を、フォーク元のリポジトリへ反映するよう依頼すること。 |
.gitignore | 履歴管理の対象外とするファイルを登録するところ。対象範囲は各リポジトリ。 |
.gitignore (グローバル) | 履歴管理の対象外とするファイルを登録するところ。対象範囲は全リポジトリ。 |
恐らく太字部分がよく使うのではと…
ただ、用語の言い方が違う所も多いので参考程度で…
(自転車をチャリやケッタっていうぐらい違う)
GitHubアカウントについて
私はGmailで登録してます。
『GitHubに登録する』を選択すると
登録画面に行くので必要事項を登録する。
細かい部分は他に詳しく解説している所があるのでそこを参照した方がよい。
登録できるとこんな感じ
・・・Udemyやってるのがばれるなぁ~
gitのインストール
MacとかLinuxではまだ試していないから分からないがWindows機においてはコマンドプロンプトでは結構しんどいってか出来ないので
gitなる物をインストールする。
こいつはLinuxやMacのターミナルみたいに使えるもの
インストールするとGit Bash
なるアイコン君が出来るのでGitの操作に関しては今後これをメインとしていく。
Gitをコマンドで使ってみる
コマンドを全部覚えるなんて無理!
最低限の物のを記載
(今後増えるかは進捗しだい…)
①リポジトリのコピー(Clone)
ローカルリポジトリの設定と作成。
基本的にはこの流れとなる。
今回はリモートリポジトリに作成した.mdファイル
を持ってくるてい
ローカルにユーザー情報をセットする。
$git config --global user.name "<username>"
$git config --global user.email "<email>"
ここでのusername
とemail
はアカウント登録時に設定した物
設定した情報の確認
$ git config --global --list
リモートリポジトリをCloneして、ローカルリポジトリを作成する。
$ git clone <リモートリポジトリのurl>
リポジトリURLについては上記赤枠をコピーする
$ git config https://github.com/*****/○○○○○
って感じで打ち込む。
ただこのまま普通にダウンロードするとwindowsでいう所のUserにファイルが来るので
予めデスクトップ上など管理し易い所にフォルダを新規作成しておき
cd ※※※※
でそこに移動してダウンロードする事をお勧めします。
git bash
立ち上げ時
cd Desktop
でデスクトップに移動
どこで作業するかは個人の好みだが、私的にはデスクトップが楽だった。
(フォルダ置きすぎてデスクトップめっちゃ汚いけど…)
↑デスクトップ上のどこかにもってきた物が出来る(これがローカルリポジトリになる)
git clone ~
でリポジトリを持ってきて確認までの一連の流れが上記
ls -a
は隠しファイルを含めたディレクトリ内データ
.git
がgitの設定ファイルとなります。
また、git remote -v
と入力する事で
ローカルリポジトリに紐づいているリモートリポジトリを確認出来ます。
fetch
は取ってくる場所(remote → local)
push
は持っていく場所(local → remote)
簡単に言えばこんな認識をしています。
②ブランチの作成
ブランチ(branch)
『履歴管理を枝分かれさせてたもの。ブランチを使うこちにより、複数の履歴を並列に管理できる。』
リモートリポジトリからローカルリポジトリにクローン(コピー)してきたファイルを
直接変更するのではなく一旦別ファイルとして扱う事
まぁバックアップファイルを作成してそこで変更するってイメージです。
ブランチの一覧を表示する
git branch
現在のブランチの場所が分かります(グリーンはアクティブなブランチ)
新しいブランチの作成
git branch <branch-name>
変更するデータに紐付いた名前(他人も理解しやすい名前)にする事。
作成後、git branch
で一覧確認すると
作成した物が表示されます。
作業するブランチの切り替え
git checkout <branch-name>
上記コマンドで作業ブランチが切り替わります。
新しいブランチの作成と同時に作業ブランチを切り替えるには
git checkout -b <branch-name>
これで作成⇒切替が出来ます。
③データを変更してリモートリポジトリに反映する準備
Remote
からlocal
にclone
したデータをbranch
したworking directory
で変更して
add
してStaging area
にcommit
して…
初心者はここで詰まる!
用語が分かりにくい!
どこぞの意識高い系コンサルタントが話す横文字か!っと思いました…
今回はまず、ローカルに持ってきたREADME.md
を変更する所からいきます。
その前にまずは作業状態はどうなっているかを確認する
git status
持ってきたデータを触っていなければcleanだよと表示します。
持ってきたデータを編集すると
(今回はVScodeでファイルを直接開いて、文章追加してます。)
変更前
ここでもう一度git status
を打ち込むと
変更されたよと表示されます。
次に変更したファイルをStaging area
簡単に言えば変更した物を纏める箱みたいな物
言い方としては他にインデックス(index)
とかステージ(stage)
とかもあります。
git add <filename>
git add.
上記はディレクトリは以下の全てのファイル。フォルダをStagin area
に送る。
複数のファイルを変更等行った場合はこれの方が楽と思う。
④コミットする。
今まで変更したデータがworking directory
に出来る
↓
まとめてローカルリポジトリに反映する為、Stagin area
に纏める
ここでいよいよローカルリポジトリに変更したファイルを反映します。
それがコミット(commit)
だそうです。
git commit -m "<commit message>"
コミットメッセージは今からコミットするデータは『何をしたやつ』を端的に表す為
メッセージを入れるのがマスト
これでコミットされます。
コミットした後にgit status
で確認すると
working directory(working tree)
には何もないとなります。
コミットした履歴の確認
git log
これでローカルリポジトリに変更履歴が反映されます。
一番上に表示されるのが最新コミット
やっぱりコメントがないと何をしたものなのかわからないですね。
⑤ローカルリポジトリの情報をリモートリポジトリに反映する
大元のリモートリポジトリに、ローカル側の情報を送る事をプッシュ(push)
するというらしい
ただ、個人でGitHubを使うだけならすぐにpush
しても問題ないが
複数人のチームで色々と行っている場合、リモート側が更新されている可能性があるので
上げる前に一度確認する必要がある
そいつがプル(pull)
という
git pull <remote_ref><branch name>
どこからpull
してくるのかを指定する必要がある
詳細は↓に
git remote -v
を入力するとローカルと紐づいているリモートが表示されます
ここの上段がリモートでorigin
を<remote_ref>
に入力すればOK
<branch name>
はmain
と入力
そうするとリモート側のmain branch
が更新されます。
確認する癖をつけた方がよいと思います。
ローカルからリモート側にpush
する。
git push <remote_ref><branch name>
remote_ref
については前述と同じリモート側のorigin
を指定
branch name
は『ローカル側アクティブブランチ』を指定する
今回の例で言うと、自分が作業しているbranch
の名前となります。
これはいきなりリモート側のmainを変更するのではなく
リモート側にローカルで作業していたブランチ(ここでいうkai-branch
)を作るイメージです。
リモート側に新しいブランチが出来たと表示が出ます。
GitHub側で
正常にpush
されていれば上記の様になります。
⑥プルリクエストをマージする
また分かりにくい横文字が来ました。
マージとは『異なるブランチの変更を反映させること。お互いの変更履歴が残る。』 ≠ リモート側を変更する
プルリクエストは『フォークしたリポジトリでの変更を、フォーク元のリポジトリへ反映するよう依頼すること。』 ≠ 変更依頼
イメージとしては
メンバー:『ローカル側で色々と触ったやつ上げたから変更してよ』
↓
リーダー:『確認するからちょっと待って』
↓ ~内容確認~
リーダー:『OKだからリモートのmainに反映するわ』
って流れで認識してます(本当は違うはず)
pull requestを作成する
pull request
を選択する。
New pull request
を選択する。
base:main
← compare:base
となっているので右側を選択して、プルリクエストしたいブランチを選択する。
変更箇所の差分が表示されるので問題なければ『Create pull request』を選択する。
何かコメントを入れて『Create pull request』を選択する。
これでプルリクエストが行われました。
基本的にはチーム単位で作業を行うのでプルリクエストを行った人以外の人間が確認する。これがマージとなります。
pull requestをマージする
個人としてやる場合は気にしないでよいが
チーム単位でプロジェクトを進めていく場合はきちんとルールを決めておこう事
リクエストで上がってきたもの(ここでいうupdate readme
)を選択する。
変更箇所については『Files changed』を選択すると確認出来ます。
変更箇所を確認したうえで、『Merge pull request』を行い完了すると
成功したぞと出る。
これでリモート側のデータが更新されます。
⑦ローカルリポジトリを更新する
リモート側を更新しているのでローカル側も情報を反映する(要はpull
する)
(ローカル側が更新前のままだから)
注意点としては、ローカル側でcommitしたファイル(kai-readme
)をローカルにマージするのではなく
リモート側からpull
を行い、メインブランチを更新する。
ただ、pull
についてはアクティブブランチに適応されるのでメインブランチに切り替える必要がある
git checkout main
これで切替(復習)
git pull origin main
これでローカル側のメインブランチを更新する。
⑧不要なブランチを削除する
ローカルリポジトリのブランチ削除
git branch -d <branche-name>
メイン(リモート側)にマージしていない場合は削除出来ないみたいです。
また、ブランチを削除する際はmain
に切り変えておくこと
これで不要になったブランチは削除されます。(打ち間違いはデフォ)
リモートリポジトリのブランチ削除
『branch』を選択する
ゴミ箱アイコン君をクリックすれば削除されます。
リモート側についてはこれで完了
⑨スクリプトのアップロードについて
意外と簡単だったのがびっくり
ファイルをドラッグアンドドロップで行けた
まとめ
多分ここまでが基本的な操作と思います。
ちなみにssh接続については…個人としてはやっていますが
現時点では別に問題ないと思っています(プロジェクトを上げないので)