Git(HubDesktop)の基本編集なんちゃら

ききよ

2023年2月5日 12:36

GitHubDesktopでプロジェクト編集の基本的な振舞のまとめメモです。

プロジェクトが完成したらレポジトリは削除する

想定されているゴールはこれです。
永遠にgitが関与している状態にしているということはしません。
これに伴い以下は余り推奨されない使い方です。

古いバージョンの保管用に永続して使う
根幹となるシステムを元にbranchで派生したプロジェクトを一括管理する

なので

のような拡張機能のテスト環境の保管のようなものを作るのは想定されていない使い方です。

commitした内容は.gitにどんどん蓄積されていくっぽいっすね。

リモートリポジトリGitHubに上げる場合も、Default branchをDLしやすい様にしているので、Other branchに最新バージョンがあると非常に不便です。
HEADがどこにあろうがTOPはDefault branchですし。

プロジェクトが完成したらレジストリからファイルを脱出させて
レジストリを削除しましょう。
(エクスプローラーで
レジストリフォルダからファイルを切り取って別のフォルダに入れる)

レジストリ削除手順

tip:エクスプローラーで直接削除でもだいたい同じ。

Also move this repository to Recycle Binにチェックを
入れると作成したリポジトリ自体が消える
入れないとGitHubDesktopのリストからだけ削除される。(リポジトリは残る)

リストから削除した場合、「Add local repository」で戻せる。
戻した時、branchなど情報はそのまま。

消したリポジトリはゴミ箱に入っているので、エクスプローラーでctrl+zでも戻せます。

基本的な進行方法

以下の図のようにbranchを分岐させて進行します。

~~なんか正式な名前があったんですが忘れました。~~
GitHub Flowです。(23.04.23追記)

https://gist.github.com/Gab-km/3705015

これの良点はreset --hard を極力使わず、見やすいcommitを保持しながら不要になったbranchを削除して最小限のフォルダサイズに抑えることができる点です。

テキストファイルとバイナリファイル

バイナリファイルはテキストファイル以外全てを指します。

どちらのファイルも記録され、元に戻すことができます。
基本的にテキストファイルはどこを変更したのかまでわかりますが、
バイナリファイルは「変更があった」というシグナルしかわかりません。
(あと変更した人物と時間)
バイナリファイルのうち、画像ファイルは変化前と変化後が表示されます。

なお、テキストファイルでもunicode(UTF-16)のファイルはバイナリファイルとして判定されます。

画像のバイナリファイルの場合
変更したとき、同じファイル名だと
削除→追加という判定になる。

.gitignore

Changeタブの判定変化したファイルから外すファイル名を記入します。
一時保存ファイルのtempや、officeだと「　$~【ファイル名】.【拡張子】」のファイルや、リモートリポジトリ(GitHub等)にアップロードしたくないファイルを入れます。

一時保存ファイルが観測対象になっていると、編集中のバイナリファイルを閉じないとcommitやsquash、branchの移動ができません。

changeタブにある変化したファイル一覧の右メニューから
ignore~のいずれかを選ぶ。
ignore file ~はそのファイル単品(【ファイル名+拡張子】が記入)
ignore all ~ はその拡張子全て(*.【拡張子】が記入)
上記を行うと.gitignoreファイルが生えます。

新規レポジトリ作成時に.gitignoreファイルを作成していれば直接記入も可能です。

注意

ファイル名を変更したとき、そのファイル名、変更後のファイル名がignoreファイルにある場合、margeやcherry-pickで合成ができません。
つまり、そのファイルやフォルダが合成後に消えます。

CONFLICT衝突

CONFLICTは状況Aから状況Bに変更するコマンドをするとき、
両方に同じ名前で中身が違うファイルがある場合に発生します。
直前の動作で変わりますが、大抵の場合
そのファイルをエディタで開くように誘導されるか、
バージョンの最新か古いどちらを採用するかの2択に誘導されます。
中止することもできます。
リモートリポジトリからフォークするとき以外にもファイルを戻したり合成するとき、ローカルリポジトリ内でも発生します。

以下のいずれかで解決しない限りGitの他の動作を受け付けません。

動作を中止する

ChangeタブからCONFLICTファイルを右メニューでDiscard change…で処理を中断します。
CLIだと

git 処理内容 --abort

と同義です。

エディタで直す

ChangeタブにConflictが発生中のファイル一覧が出ているので、右メニューから
Open in ●● を開くとこんな感じで出ます。これはAtom。

採用する方の「Use me」ボタンを押して保存して閉じればOKです。

バージョンを指定する

conflicted fileが紹介されているalertにて▼ボタンを押すと
Use the ～が出ます。
上が母体、下が子体です。変更するなら下。

Marge合成

branchAにbranchBを合成します。
この時、母体がAだとすると、Bのcommitのhistoryが全てAに合成され、
「 Merge branch 'branchB' 」がAのhistoryに作成されます。branchBは以前のまま残ります。

BranchメニューからMerge into current branch…(Ctrl+Shift+M)で行えます。

注意：
「 Merge branch '' 」のcommit以前のcommitに対して
Squashやcommitの移動ができなくなります。

元に戻す関連

結果的に、現在のファイルAを過去バージョンのファイルAにする方法を
まとめました。
CLIを使えば元に戻したのを元に戻せますが、それぞれの機能を一度別branchで試してから本番データで試すのがいいと思います。

commitの前に直前のcommitまで変更を削除するDiscard changes…

changeタブの変更履歴の元に戻したい項目で右メニューを出してDiscard changes…を押す

commitの後でリモートリポジトリにあげる前までのcommitを削除するUnde commit

最新commitの右メニューからUndo commitを選択。
あとは上記Discard changes…と同じ。

つまり、ローカルレポジトリでは最新commitから順にcommitを削除することができます。(Squashとresetを除く)

同branchの特定のcommitの内容で最新commitを上書きするrevert

主に最新のcommitで追加した機能(commit)を取り外す用途で使います。
取り外すなので、後でまた付ける予定がある場合に最適です。

上書きしたいcommitで右メニュー
Revert changes in commit を選択

正確には、選択したcommitで消した記述と追加した記述を逆転させます。
それら差分の記述が最新部分(HEAD位置)にない場合conflictが発生します。

消した記述がないファイルはrevertできない。
そのcommitで初めて作成されたファイルとか。

「変更する場所がない」エラーが出ます。
Changeタブに切り替えて該当ファイルのcommitを

Dscard changes してcommitボタンを押せばrevertが完了します。

消して(赤)、追加(緑)した記述があるファイルはrevertできる。
「一番目」が追加され、「2番目」が削除されます。
ただし、最新ファイルは「3番目」という記述で、上記には存在しない。ので。
CONFLICTが発生します。

CONFLICTの時…

changeにconflictしたファイルがあるので、右メニューから設定しているエディターをOpen。
<<<<HEADとかの記述も含めて削除して残したい記述以外を削除します。

Atomで開いた様子。使う方のボタンを押します。
「3番目」(変更しない)のか
「一番目」(変更する)のか

**つまり、3番目を一番目に変更するcommitを作成するのと同義になる**ので、
この状態でcommitします。

ちなみに・・・

revert元に戻すなので

最新commit(3番目に変更)をrevertして、(赤線)
「2番目に変更」と同じになった「Revert"3番目に変更"」が最新の状態で
「2番目に変更」でrevertすると、
「revertのテスト」と同じになった「Revert"2番目に変更"」になります。(青線)

revert連打で、元に戻るボタンを連打して戻るみたいなこともできます。
ただcommitが消えるわけでなく、元に戻したcommitが積みあがります。

別branchの特定のcommitの内容で最新commitを上書きするcherry-pick

その選択したcommitのみを、現在のbranchのcommitに積みます。Squashなどで圧縮したcommitを拾うなどで使います。
margeだと欲しい機能以外のものも合成してしまうので、
最小1commitから選んで合成できます。

入れたいcommitがあるbranchに移動して、
HistoryのcommitをつまんでCurrent branchタブまでオンマウス
入れるbranchの上まで持っていき離す。

複数のcommitをcherry-pickしたい場合は、Shiftとかctrlとかで複数のcommitを選択した状態で上を行います。

commitの右メニューのCherry-pick commit…
でも同じことができます。

CLIの場合別branchから現在地へ呼び出すイメージですが、
GitHubDesktopの場合目的地へつまんで持っていくイメージです。

conflictは同じ名前のファイルで違う記述があれば発生するので、cherry-pickでも場合によっては発生します。

Squashと合わせて使う機会が多いと思います。

conflictが発生した時、エディタを開くか、
プルタブから優先させるbranchを選びます。
Useの上が母体で
Useの下が子体です。
子を母に持ち込むので下を選びます。
変更したい場合はつまんできた方のbranchを選ぶわけです。

同branchの特定のcommitの内容の特定のファイルだけを最新commitに上書きするcheckout(restore)

初めに。checkoutは動作は一つで効果は多機能をいう面を持っています。
やってることはHEADの移動だけですが、効果はbranchの変更するとか、特定のファイルだけを変更(復活)するなどあります。

GitHubDesktopではcheckoutで特定のファイルを変更するという機能がないので、CLIコマンドラインを使います。

CLIコマンドラインの起動は

これ見てください。(拡張機能を入れる-クローン)

ショートカットキーはctrl+@(`)です。

$ git restore [ --source SHA値 ] ファイル名.拡張子
または
$ git checkout [ SHA値 ] ファイル名.拡張子

[ ]の中身を省略すると、最新から直前のcommitの状態になります。
実際入力するときは[ ]　の記号はいらないです。

tit:TortoisGitが入っていれば以下の手順で行えます。

エクスプローラーからプロパティを選ぶ

①ログから戻したい場所をクリック
②戻したいファイルを選択、右メニュー表示
③「このリビジョンに戻す」をクリック

同branchの最新のcommitから特定のcommitの間の変更を削除して特定のcommitにするreset --hard

resetは3種ありますが、GitHubDesktopで効果を持つのはhardのみです。

特定のcommitの右メニューから

git reset --hard 【SHA値】

[ 最新commit～選んだcommitを含まないcommitまで ]を削除して、
[ 選んだcommitの状態 ]にレジストリを上書きします。
選んだcommitの時点で存在しないファイルは削除されます。

HEADが一番上にあり、青選択のSHA値を使った場合、
青選択から上全てのcommitが削除されて、最新が青選択部分になります。

CONFLICTは発生しません。

resetを取り消したい場合はCLI(ctrl+@)で

git reflog

で自身のアクションのログから【ログのID】HEAD@{N}を取得して

git reset　--hard 【ログID】

でresetし直します。

変更を保存しつつ、より過去(または未來)のcommit位置に移動するSwich branch(git checkout)

分岐したbranchを移動することで、そのbranch当時のレジストリの中身に現在の中身が上書きされます。
その時なかったものは削除されます。その時あったものは復活します。
元のbranchに再移動すれば全て元に戻ります。
なお、自分の現在値をHEADといいこれの移動をCLIでは行います。