【自分とこの環境下におけるGit & GitLabレクチャー】
更新履歴
2024/02/29:ブランチの作成・変更にcheckoutではなくswitchを利用するように変更
概要
いつも行う手順を記載．
ツールなんだから，考えながらやるのではなく，頭を使わなくて出来る方法があればそれが一番．
タグ名・ブランチ名のちゃんとしたものは独自ルール:多人数開発のためのGitLab・タグ・ブランチを参照のこと．
手順
-
対象を適当なとこまで作成(個人差あり．プログラムなら中身ないmain関数つくるところからα版まで幅広いと思う)．
-
ある程度まで出来たらgit開始．
git init -
.gitignoreの準備
-
gitlabにプロジェクト作成，remote add，最初のpush．プロジェクト作成時に"README.mdを作成しない"にチェックを入れて作成しないほうが吉．
git remote add origin ***(gitlabで提示されたURL) git add . git push -u origin main -
ここまででmainブランチが作成されている状態．大きな方針としてmainブランチを直接編集するのではなく作業用のブランチを作成し編集，編集後に統合．
-
新しいブランチを作成し(ex. develop-add_func)，編集作業開始．
git switch -c develop-add_func あとは編集作業．．． -
作業が一段落したらコミット．
git add . git commit -m "コメントはなんか書く癖をつけておく"もしadd/commitしたくないファイルがある場合git add <add/commitしたいファイル> git commit -m "コメントはなんか書く癖をつけておく" git stash -u -
mainブランチへ戻ってマージ(develpブランチの動作はもちろん確認しておくこと)．
git switch main git pull git merge develop-add_func git push -
必要に応じてタグ付与．
git tag -a 1.0.0 -m "1.0.0はバージョン．バージョン・メッセージはちゃんと書こう．" git push --tags -
続けて編集あればdevelopへ戻って作業再開．基本的には1ブランチ1作業なので，本当に一時的ついているならブランチを削除＆新しい編集用のブランチを作成．
git switch develop-add_func git stash pop
最後に
ちょっと前提
分からなければ読み飛ばして可．
- mainブランチは極力直接編集しない．いつでも使用できるようにしておく(プログラムならコンパイル・実行可にしておく)．
- 直接編集するのは他のブランチ．そのブランチの編集が一段落し使用できることを確認したらmainにmergeする．mergeの間隔としては，大きな変更ではなく小さな変更を心がける．
- 他の人との共同開発などもあるため，「知らないmainのアップデートがあるかも」を頭においておく．
stash便利
分からなければ読み飛ばして可．
小さな変更の際に，「このファイルはとりあえず作ったけど次のmerge変更で本格的に使うから今回のmergeに入れたくない」や「ブランチのテスト用の本当に一時的なファイルだからcommitとして残したくない」など，add/commit/mergeの対象にしたくない場合に便利．
このベージでは，とりあえずgit stash -u,git stash popを使っているがちゃんとした使い方などは以下が参考になる．