はじめに
この記事では
バージョン管理システムのGitを
職場で使うことを想定して
Gitの使い方についてまとめた記事です。
今回はGit関連のサービスは使えないけど
リモートリポジトリは作成できる人向けに書きます。
ベストプラクティスや間違いがあれば
それなりに良い方法で書き直していきます。
あざやかにバージョン管理をキメたい
前回の内容に加えて
もしかするとこういうコマンドもあると
やりやすくなるのではというのがあったのでその続き
正直なところ職場だったら
Gitを操作できるGUIをクライアントを
導入すれば解決なんじゃないかと思われry
効率を最優先にとっても
ソフトを導入することは
あまり良い選択肢ではないと思います。
なにゆゑそう思うか
効率を最優先にとっても
ソフトを導入することは
あまり良い選択肢ではないと思います。
これは私の持論ですが主に理由は２つ
・ソフトを扱えることでその技術が扱えると勘違いする人が登場すること
・ソフトのサポート終了した瞬間その技術が使えなくなること
簡単に言えば
「GUIのソフトウェアがなければその技術を扱えない」
というハンデキャップをわざわざ負いに行くことはないんじゃないかな
ということと
ニッチな技術でとんがるより
みんなが愛してやまない技術を使ったほうが
自身の市場価値は測りやすいとも思うからです。
今回登場するコマンドー
$ git clone [リポジトリURL]
$ git push origin [ブランチ名]
$ git merge [ブランチ名]
$ git branch -D
$ git branch -d
想定される環境
客先常駐
GitHub使用不可
Windows10 Pro 64bit
Git 2.26.2.windows.1
想定される利用者
研修中のエンジニア（例えば、業務未経験者など）
初学者を教えるベテラン、中堅エンジニア
リポジトリのコピー(git clone)
リポジトリのURLと書きましたが
.gitフォルダのあるリポジトリのフォルダパスでも使えます。
たとえば、clone元のリポジトリ（test）が
別のディスクドライブ（仮にF:）にあるとき
以下のように入力することリポジトリをcloneできます。
$ git clone F:\test
cloneしたあと
clone後に
内容を変更してaddして
commitすると
変更されるリポジトリはどこでしょうか。
答えは簡単です。
clone先のリポジトリです。
このときclone元のリポジトリは変更されません。
clone元を更新したい
clone元を更新したいときはpushを使います。
例えば、clone元のリポジトリのmasterブランチを更新したいときは
カレントのリポジトリをcommitしたあと
以下のように入力すること更新できます。
$ git push origin master
改修とレビューのサイクルを作りたい
実際に作業する人とレビューする人に
分かれて作業するときのことを考えてみた。
作業者側
1.git clone
2.git branch -b test
3.コード改修
4.git add
5.git commit
6.git push
こうすることでclone元リポジトリには
testブランチという草が生える。
間違ってもmergeしないように！！！
レビュー者側
何をレビューするかについての議論が先かとは
思いますがこれについては
次回以降まとめます。
作業者側の作業が終わったと仮定して話を進めると
1.git clone
2.git merge
3.レビュー
4.git branch -d test
5.git push origin master
工程の3で問題がなければ4と5に進む
レビューNGならば作業者にもう一度、同じ手順を踏んでpushしてもらう。
この運用の問題点
・作業者がtestブランチを切り忘れたままcommitしてしまう可能性
・レビュー者がマージ完了後のtestブランチを削除し忘れる可能性
問題点その１
作業者がtestブランチを切り忘れたままcommitしてしまう可能性
これについては
作業者のフローである工程2の後に
git branchを叩くことで
ポカを回避できそう。
問題点その２
レビュー者がマージ完了後のtestブランチを削除し忘れる可能性
これについてはレビュー後か
merge後に
git branchを叩くことで
ポカを回避できそう。
まとめ
git branch めっちゃ大事なコマンドでは？？？
来月あたりから実際にこれで運用してみようと思います。