Git commandのチップス
海洋ロボコンをやってた人です。
今回は、Gitのコマンドや各種利用について個人的にまとめるページが欲しかったので、まとめることにしました。
記事のゴールは、利用したい目的に応じて私または読者がコピペでgitコマンドを利用できること. とします。
誤記等あればご指摘ください。またブランチの概念など詳細は省いていますので、詳しく知りたい方はReferenceを参照ください。
どうぞよろしくお願いいたします。
1. git command list
手元にあるgitコマンド一覧のメモを下記に記載したので、適宜参考にしてください。
1.1 ローカルからリモートへpushするまでの一連の操作
mkdir package_name
cd ./package_name
## Gitリポジトリの初期化
git init
## Gitリポジトリ内の変更されたファイルをステージングエリアへ追加
git add *
git add repo_name
## Gitリポジトリ内での変更一覧を表示
git status
## Gitリポジトリ内の変更をコミット(-mでコミットメッセージを記載)
git commit -m "Initial commit"
## originというリモート名のリモートリポジトリを作成
git remote add origin [remote URL]
## ローカルのGitリポジトリをリモートリポジトリに送信
git push origin master
直前のコミットをなかった事にする場合は下記。
git reset --soft HEAD^
commit コメントのテンプレートは下記参照
1.2 リモートリポジトリから更新を取得
## リモートリポジトリの更新をローカルリポジトリに取得しマージする
## git pull <リモートリポジトリ名> <リモートブランチ名>
git pull origin master
## リモートリポジトリの更新をローカルリポジトリへ取得、ローカルは更新されない。
## git fetch <リモートリポジトリ名> <リモートブランチ名>
git fetch origin master
git merge master
pull と fetchの違いは下記参照。一気に反映させるならpull, 作業中ならfetchで切り分けのイメージ。
1.3 ブランチの作成と切り替え
## ブランチの表示
git branch
## 新しいブランチの作成
git branch humble-devel
## ブランチの切り替え stashとか使うのが良い
git checkout humble-devel
## 新しいブランチを作成し、ブランチを切り替える
git checkout -b humble-devel
## humble-develブランチをmasterブランチにマージする
git checkout master
git merge humble-devel
git push origin master # リモートリポジトリにマージをプッシュする
ROS関連の場合、ディストリビューション単位でブランチを切られることが多い。
SW開発の場合、ドリブン開発という形でrelease/***, feature/***と命名されることが多い
1.4 git cloneの種類
## ブランチを指定してクローン
## git clone -b <ブランチ名> <リモートリポジトリURL>
git clone -b humble-devel https://github.com/tasada038/ros2_rs_pcl.git
## サブモジュールを含むリポジトリのクローン
git clone --recursive <リモートリポジトリURL>
## Git管理環境が変わる、複製管理するときに利用
git clone --mirror <移行/複製元URL>
git push --mirror <移行/複製先URL>
## 指定したコミット数でクローン, commit数が膨大で時間がかかるときに使用 --depth 1は良く見る
git clone --depth 5 <移行/複製元URL>
1.5 tag設定
T.B.D
1.6 config設定
## .gitconfigの設定
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
2. Received Pull Requests
ありがたいことにPull requestsをもらいました。
PRもらってから、mergeするまでの流れを下記に記載します。
git checkout -b develop
git pull [PR依頼者のremote URL]
git push origin develop
git checkout -b master
git merge develop
# marge commit したくない場合は以下を使用
git merge --no-commit develop
git status
git add *
git commit
# end merge --no-commit
git push origin master
ここまで行うと、Merge pull requestという緑のボタンを押さなくてもGitHub上でもmerged commitされPRはCloseされます。
あとは丁寧にお礼を書きましょう。
3. Send Pull Requests
Pull Request発行してmergeされるように活動をする。
3.1. ForkリポジトリのPR
ForkしたリポジトリのPRを行う場合は下記の手順で進める。
-
①Fork元のリポジトリを開き「New pull request」を選択する
-
②「compare across forks」を選択し、head repositoryから自身の変更をpushしたブランチを選択する
- ③下図のようにソースコードのDiffを確認し、対称ソースファイル単位でコメント入力が必要な場合は「Commit message」の箇所をクリックしソースコード行数単位でコメントを入れる。
- ④ Title, PR messageを記載し「Creat pull request」を選択しPRを送る。
必要に応じてGit AppのEclipse ECA Validationをインストールし、GitHub PR貢献の検証設定をしておく。
Appendix. Github Actions
Github Actionsについては下記参照。あとはrunnersについてメモレベルで記載します。
GitHub-hosted runners:
- GitHubによってCI/CDが管理される
- GitHubプランの無料分があり、それを超えると有料となる
Self-hosted runners:
- 利用者の管理するクラウドサービス、ローカルマシン上で動作せせる
- その分ランナーマシンの維持コストが利用者持ちとなる
GitLab-hosted runners:
DevSecOps(デブセックオプス)というDevOpsとSecurityを組み合わせた開発に特化したGitLab上で動作させるランナー。
ファイアウォールルールはVM間の通信許可をしないこと、エフェメラルVMからパブリックインターネットへの送信通信のみを許可するなどセキュリティ対策が取られていることが特徴
Reference
以上です。
Likeいただけると大変励みになりますので、よろしくお願いいたします。
Discussion