個人で自由に開発する場合
基本は、git commit , git push , git pullとかでいけると思います。
何個か前のversionをソースコードの変更をせずに、起動させてアプリの動きをみるだけなら、
Source Treeで過去のVersionをダブルクリックして、「OK」をおせばそのversionにローカルのソースコードが変更されてます。
実際にWebシステムが稼働したあとや複数人で進める場合
自分の事例では、稼働したwebシステムのデザインを変更させる場合、させない場合の二つで分岐して
そのどちらかいい方を選んでもらいつつその後の機能の追加開発を行うというシチュエーションで、初めて実践で”branch”なるものを使った方がシンプルかつ素早く方針転換に対応できるかつ気楽と、感じたので使うことにしました。
ブランチの使い方(自分の主観多め)
おそらくブランチの基本的な使い方は、少し不安な作成はブランチをつくり、そこで開発を進めて、よさそうなら、あとからmainに合流させて、ブランチは削除する、みたいな使い方が一般的？かと思います。ひとことでいうと
ブランチは「安全に新しい作業を進める」ための便利な仕組み
作業が失敗してもmainに影響を与えませんし、一時的なブランチを作り、試してから統合するか決められます。
さて、私の状況:
先走り気味かつ提案していくスタイルの自分はすでにMainのブランチにデザインが反映されている状態です。図解すると以下のような感じ。
ぱっと思いついた考えは、現在の場所#4→デザイン付与VerでひとまずOKだとして、
もう一方のデザイン付与してないVerからも追加機能を機能を加えた動きの序盤をクライアントに見てもらう必要があるので、
#4から#1にもどって、そこからブランチ(枝)を派生させて、追加機能をつければいいんじゃね？
という案です。※後々この案よりいい案をおもいついたので却下されますが、ひとまずこれをやるうえでのgitの操作は成功したので自分用にメモです。
動き①に関しては、自分はSource Treeから操作したので以下のような感じです。
すると、下のポップアップがでてきます。
ここからは、自分の何回か試した感じなので、詳細は各々調べること推奨ですが、
概要は、過去の場所にもどってそこをみるだけやwebアプリを起動して最新との違いをみるだけならいいですが、過去の場所から変更していく場合、その上位にあるコミットは下手すれば消えます。 なのでgitに慣れてない人はむしろ未来に向けて、ブランチを作った方が良い、という経験則から上記の警告がきていると思います、多分。
まあ、結果そのやり方で自分も実際は対応することにしましたが、対応力を広げるためにも警告を無視して、「はい」をおすと↓のポップアップがでます。
ちなみに、クリーンにチェックをいれて、OKをおすとローカルでのgit上記の履歴はきえます。
それでも、リモートリポジトリに履歴は残っているのでgit pullすると再生します。
ひとまず、クリーンをチェックせずに、「OK」を押します。それでも上位の履歴はきえます。
このとき、対応するローカルのソースコードも上記のVersionまで戻ってます。
いったんgit pullしてもとに戻しましょう。↓
ひとまず、1つ試行をして、再生したのが今の状態です。
つまり、動き①と動き②は一緒にした方がスムーズそうなので、ここからが、成功例です。
そして、ブランチをつくりましょう。
あとは、派生させたブランチでどんどん作業を進めていって、派生させたブランチはmainに影響を与えないので、かつそのブランチは簡単に削除できるので気楽です。
そして、派生させたブランチが良くできてmainに合流させるときは、Margeをします。
このMargeをする前に、複数人で開発をすすめている場合にはフレームワーク等使っていても他の人のコードに影響を与える書き方をしている可能性もありますので、Pull &Request機能があります。
自分の触った感じだとPull&RequestはおそらくgitHubを通さないと使えない機能です。他の機能はgitHuBからもできますし、gitコマンドだけでもできます。
ちなみに、Pull &Requestは、ひとことでいうと、
「コード変更を他の人に確認・レビューしてもらい、ブランチを統合（マージ）する提案」
です、Pull &Requestだけでは基本的にMargeされないのでその後、権限がある人がMargeを実行して、
ブランチでの開発はmainに統合されます。このときに、コードのConflictが起こると面倒です。
ひとまず、問題なくmargeできたら、不要なブランチは削除してもよいかな、と思います。
ただ、今回の自分の事例だと、Margeじゃなくどっちか一方の案を最終的には通すので、
main(デザイン付与ver)を通すか派生したブランチ(design_less_branch)どちらかに最終的にきまり一方が消えてもらいます。その際に、mainが採用されたなら、design_less_branchはぱっと削除しておさらばですが、
design_less_branchを採用する場合、mainの内容はdesign_less_branchの内容に完全に置き換えられてその後、design_less_branchは削除する必要があります。(※mainはメインのため、開発の主軸ですので(自分の感覚ではmainは木の幹))
その際に、source Treeからはどうやらその操作ができなかったのでgit コマンドで行いました↓
$ git status ←mainに反映させるため、現在チェックアウトしている場所を確認しましょう。
On branch main
Your branch is up to date with 'origin/main'.
-----------------------------------------------------------
nothing to commit, working tree clean
-----------------------------------------------------------
$ git reset --hard 派生したブランチ名 ←コマンド➀
HEAD is now at 8d49084 ブラントテスト3
$ git push origin main --force ←コマンド➁
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/HirayamaKenta/003
+ 50cf4a9...8d49084 main -> main (forced update)
コマンド➀とコマンド➁を行いますと、mainと派生したブランチ名のhistoryは完全に一致します。
その後、不要なら派生したブランチは削除でもOK。
おまけ:結局自分の中で採用したやつ
結局mainの最新位置(デザイン付与済み)から、ブランチを派生させてそこで、デザイン付与コミット3つを一気に打ち消して(Revelt)、機能を追加させていくことに決めました🤞
ReveltはsourceTreeではワンクリックでできるので、手軽ですし、ReveltのRevelt(打消しの打消し)もできるので、結果自分の履歴の抜け漏れがなくなりそっちの方がいいかなと思いました。
ですし、git的にも過去に戻って枝は派生させるよりも、これからの未来に枝を派生させてそこに色々試行錯誤するほうを推奨していそうですしね。
返信がありません