概要
- Githubの使い方あれこれを記載します。
- 私の記事は基本的に備忘ですが、今回も完全に備忘です。
- 随時更新します。
目次
- ブランチを切る/forkの違い
- gitコマンド/それを使用する流れ
- forkしてからファイルを編集してプルリクまで
- リモートからファイルを取得
- ブランチ作成からPushまで
- ブランチのcheckout（切り替え）
- マージ取り消し
- ブランチ戦略
- タグ付け
- git-mergeの違い
- リモートへのpush時のトークン設定
1.ブランチを切る/forkの違い
-
ブランチを切る
プログラムの修正や機能の追加を行うときにブランチを追加（ブランチを切る）し、担当者や機能別にそれぞれのブランチで作業を行う 。そのため、分岐したブランチの内容は他のブランチに影響を与えず、複数人が同時平行で作業を行うことができる。リポジトリは同じ。 -
fork
クローンまたはコピーの別の名前。ブランチとは異なり、フォークは元のリポジトリから独立している。元のリポジトリが削除されてもフォークは残る。リポジトリをフォークするとそのリポジトリおよびそのブランチが全て取得される。元のリポジトリとは独立しているため、元のリポジトリに影響を与えずに操作ができる。
2.gitコマンド/それを使用する流れ
forkしてからファイルを編集してプルリクまで
１：Forkをしたら自分のリポジトリに「自分のアカウント名/forkしたリポジトリ名」というリポジトリができたはずなので、クーロンを実施する。
クーロンには上記のURLを使用する。以下コマンドでcloneを実施。
git clone リポジトリのURL
cd cloneしたもの
２：ブランチをきる
#適当にブランチを切る。今回はmyworkという名前
git checkout -b mywork master
#チェックアウトしたブランチに正しく切り替わっているかを確認
git branch -a
ls
３：編集したいファイルを編集（viでもvscodeでもなんでもok
４：ファイルの編集後、git diffコマンドで修正が正しいかを確認
git diff
５：想定通り変更できていたらローカル(手元)のリポジトリにコミット
#ファイル名ではなく、. (ドット)を指定することで、当該フォルダ内のファイル全部選択可能
git add ファイル名
#適当にコメントを記入する。コメントを書くことで何の変更かがわかる。
git commit -m "XXファイルにアカウントを追加"
６：プルリクエストを発行するまえに、リモート（Github側）にローカルで修正を加えたブランチ名と同じブランチが存在する必要があるため、リモート環境でブランチを作成してforkリポジトリであるリモートリポジトリに変更をpushする。
git push origin mywork
７：本家のブランチ(fork元ブランチ)に対して、プルリクエストを実施する。
ブランチ一覧から、自分の作ったリモートブランチ(今回の例ではmywork)を選択してブランチを自分が作ったブランチに変更。これによって自分のブランチをmasterブランチに対してプルリクエストを送ることができる。
リモートからファイルを取得
git pullコマンドを実行することで、リモートリポジトリから最新の変更を取得し、現在のブランチにマージできる。
git pull origin ブランチ名 #リモートからファイルを取得する
ただし、前提条件として、以下１が存在する。２は推奨である。
１：リポジトリに移動できていること
このコマンドを実行する前に、Gitリポジトリに移動する必要がある。つまり、リポジトリをクローンするか、既にクローンしている場合はリポジトリに移動している必要がある。
２：fetchコマンドにより最新の変更が反映されていることを確認すること
リモートリポジトリから最新の変更を取得するために、git fetchコマンドを実行する。これにより、リポジトリ内の変更がローカルリポジトリに反映される。そして、git pullコマンドを実行する前に、最新の変更が反映されていることを確認するために、git fetchコマンドを実行することが推奨される。
git fetch と git pull の違いは、 git fetch はリモートリポジトリから最新の変更を取得するだけで、ローカルリポジトリには反映されず、git pullは git fetchとgit mergeを組み合わせたコマンドで、リモートリポジトリから最新の変更を取得して、それを現在のブランチにマージすることで、ローカルリポジトリに反映する。
git fetchを実行すると、リモートリポジトリから最新のコミット情報がダウンロードされ、ローカルリポジトリに反映される。これにより、ローカルリポジトリのブランチの状態がリモートリポジトリの状態と同期されるが、現在のブランチにはマージされない。つまり、git fetchを実行した後、ローカルリポジトリの変更を確認し、必要に応じてgit mergeを実行することで、最新の変更を反映することが可能となる。
一方、git pullを実行した場合、 git fetchが最新の変更を取得して、その後git mergeを実行して、現在のブランチに変更を反映する。したがって、git pullはより便利であるものの、自動マージによるコンフリクトが発生する可能性がある。そのため、変更を取り込む前に変更を確認して、手動でコンフリクトを解決する必要がある場合がある。
以上のステップを経ることで、git pullコマンドを実行する準備が整う。
ブランチ作成からPushまで
１：現在のブランチを確認し新規ブランチを作成する。
git branch -a #現在のブランチを確認 (-aでリモートブランチも参照可)
git checkout -b ブランチ名 #ブランチを作成して移動 (-bで作成したブランチに移動可)
２：ファイルを編集
３；変更をGithubに反映させる準備
git status #ファイルの編集状態の確認
git add . #コミットしたいファイル追加("."ではなくディレクトリやファイル名を指定する事で個別での追加が可能)
#Ex１：git add MyApp #MyAppディレクトリの変更分をコミット対象に
#Ex２：git add MyApp/src/compornent/App.js #App.jsの変更分をコミット対象に
git commit -m "コミット時のコメントを記載"
#ステージングにaddしたファイルをコミットする
#このとき、なんのコミットかがわかるようにコメントを記載する
４：コミットをリモートにpush
git push origin HEAD
#右記でも良い＞＞ git push origin ブランチ名
#HEADとするとブランチ名を書かなくても良くなる。
#具体的にはローカルブランチの変更がリモートリポジトリの同じブランチにプッシュされるという意味である。
ブランチのcheckout（切り替え）
git branch #現在のブランチを確認
git checkout "移動したいブランチ名" #ブランチを移動できる
#存在しないブランチ名を指定した場合エラーがでる。リモートのブランチ名を指定すると、
#そのリモールブランチのローカルコピーが作成され、作成したブランチに移動する
マージの取り消し
マージ後にやっぱりやめたい時に使います。コンフリクトが起きた時はファイルの編集をしていない時に使いましょう。コマンドは2種類あります。これを実施することでマージする前の状態に戻すことができる。
git merge --abort
# or
git revert 打ち消したいコミットID
ブランチ戦略
ブランチは誰でもいくつでも作成することができるため、ブランチのブランチやブランチのブランチのブランチ、、、といったこともできてしまう。こうなるとかなり複雑化されていき無法地帯化する。なので、ルールづけを行って、ブランチの作成基準みたいなものをみんなで守りましょうってことをした方が良さそう。そこで、計画的にブランチを作ってそれらを管理していく方法が、”ブランチ戦略”となる。絶対にこれ！というものがあるわけではなくチームやプロダクトの適正に合わせたブランチ戦略を作成することが重要。代表的なものには、以下の4つがある。これら4つの説明は一旦割愛する。GItHub Flowをもとに自分のチームでの運用に適した形にブランチ戦略を定義するなどして使うと良い。
- git-flow
- GitHub Flow
- gitworkflows
- GitLab Flow
タグ付け
Coming soon.
git-mergeの違い
Coming soon.
リモートリポジトリへのpush時のトークン設定
Coming soon.
おわりに
- 一撃で書ききれませんでした。
- このページをみれば一通りのことは思い起こせるようにしたいので、目次以外の項目も随時更新予定です。