メモ

git pullは一気にしてくれるから一見楽だが今自分のいるブランチに統合されてしまうので注意が必要 ↳hogeブランチに居る　masterブランチの情報をmasterブランチに統合したい　→pull→hogeに統合される　 ブランチはただのポインタ　同時に加発できる HEADはいま自分がいるブランチ ブランチを分ける 開発自体はトピックブランチで作成するようにする プルリクエスト手順 ①Maseterブランチを最新に更新 ②ブランチを作成 ③ファイルを変更 ④変更をコミット ⑤Githubへプッシュ ⑥プルリクエストを送る ⑦コードレビュー ⑧プルリクエストをマージ ⑨ブランチをマージ GitHub　Flowが基本

使用したコマンド

・git commit --amend 直前のコミットをやり直す　リモートリポジトリの分はやり直し×
・git remote -v リモートの情報を確認できる
・git remote add 名前　リポURL　新しく登録
・git fectch リモートリポからローカルリポに取り込む
・git merge ローカルリポからワーカツリーに取り込む
・git pull origin master リモートからワークツリーまで一気に取り込む
・git remote show origin より詳しい情報が見れる
・git remote rename <旧名前> <新名前> リモートの名前を変更
・git remote rm <リモート名> リモートの名前を削除　
・git branch <ブランチ名>　ブランチを作成
・git checkout <既存のブランチ名> 既存のブランチに移動
・git checkout -b　<新ブランチ名> 新しくブランチ作成し移動もする
・meregは３種類　
・git branch -m<ブランチ名>　自分が作業しているブランチ名を変更
・git branch -d <ブランチ名> ブランチを削除　
・git branch -D <ブランチ名>　ブランチを強制削除

タイトルは大げさでした。
「マージできない」問題を一発で解決するようなものではありません。

はじめに

このaliasは何処かで拾ったもので完全にｎ番煎じですが、これを使うようにしてから落ち着いてマージ作業が行えるようになりました。
ちょいちょいカスタマイズして現在の見た目に落ち着いていますので、使い所も含めて紹介します。

設定方法・使い方

~/.gitconfig

[alias]
    tree = log --graph --all --date=short --format=\"%x09%C(cyan)[%cd]%Creset %C(cyan bold)%<(20)%an%Creset%C(yellow)%h%Creset %C(magenta reverse)%d%Creset %s\"

使い方はgit treeと実行するだけです（表示内容はgoogletestのリポジトリから拝借させていただきました）。

GUIなツールでは良くある表示ですが、HEAD以外のブランチも含めて俯瞰（ふかん）しているのが特徴です。

使い時・使い所

git mergeやgit rebaseでCONFLICTしてパニックになる前に使いましょう。

手順としては一手間増えるのですが、git初心者にオススメするのは、

git pullではなくgit fetchを使う

ことです。

git pullというのは「git fetchとgit mergeを同時に実行」するコマンドです。
git mergeは2つのブランチを合流させるコマンドで、これが（git pullにおいて）CONFLICTを生む原因です。

では、git fetchとは何でしょうか？
git fetchはローカルリポジトリをリモートリポジトリと同期するコマンドです。同期すると言ってもワーク領域は書き換えません。git branch -aなどで目にすることがあると思いますが、remotes/origin/mainなどの.gitディレクトリの中で管理されている領域を書き換えるだけです。

つまり、git fetchはワーク領域への副作用が無いので気兼ねなく実行出来るのです。

利用シーン

1. 2人が同時にmainブランチの同じファイル・同じ箇所に修正をする。
2. 1人目が先にリモートリポジトリにpush。
3. 2人目がリモートリポジトリにpushするが失敗、「git pullで変更を統合しろ（英語）」的なメッセージが出てくる。

ここで愚直にgit pullすると当然CONFLICTします。そこでgit fetchとgit treeの出番になります。

$ git fetch
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 263 bytes | 13.00 KiB/s, done.
From github.com:utkamioka/example-git-tree
   8519b35..f387f46  main       -> origin/main
$ git tree
*       [2020-11-29] Yutaka Kamioka      89fcafc  (HEAD -> main) update readme second
| *     [2020-11-29] Yutaka Kamioka      f387f46  (origin/main, origin/HEAD) update readme first
|/
*       [2020-11-29] Yutaka Kamioka      8519b35  first commit

リモートリポジトリoriginのmainブランチ（f387f46）は、現在の作業場所（HEAD=89fcafc）の派生元（8519b35）から枝分かれしていることから、既にコミットが進んでいることがわかります。
この状態で、git diff origin/main（git diff f387f46とかでも可）で合流したいブランチとの差分を求めることができます。

$ git diff origin/main --name-only
README.md
$ git diff origin/main
（省略）

こうして、合流先ブランチと差分があること、そして差分があるファイル名やその位置を、マージ実施前に知ることができ、"CONFLICT"の文字列に慌てることなく、マージ作業に取り掛かることが出来ます。

終わりに

残念ですが、現時点ではマージそのものを簡単にする道具はありません。

マージは、プログラムコードから意図を読み取り、それを活かしつつ、別の意図をコードとして追加する、高次でクリエイティブな活動ですが、現在のAIにはそれを可能にする読解力は有りません。

しかし、マージを楽にする手法や手段は存在します。

プログラムコードを単機能でコンパクトな関数に分割し分かりやすい名前を与える、テストしやすいコードにした上で、しっかりとテストコードを記述し、機械的に検証できる環境を用意する、、、などです。
いわゆる「良いコード」はマージを楽にするコードと言えます。

gitのaliasを紹介するだけの小ネタのつもりでしたが、無駄に長くなってしまいました。?

はじめてのGIT

SESで使われる実務を見据えて必要最低限の知識を集めました。
私が考える必要最低限です。

コンテンツ

・用語
・TakeAway
・quiz

用語

・git・・・分散型バージョン管理システム
・github・・・・Gitをオンライン上で管理するサービス
・リポジトリ・・・・保管場所
・ローカルリポジトリ・・・・
・リモートリポジトリ・・・・
・CUI GUI・・・・
・modified・・・ 修正された
・fetch　・・・ 取って来る

TakeAway

which git
git --version
mkdir firstrepo
ls
cd firstrepo
git init
ls -a
git config --global user.name "Gina Tanaka"
git config --global user.email gina-tanaka@kvf.biglobe.ne.jp
git config -l
touch Readme.md
○　git status
git add Readme.md
git commit -m "はじめてコミット"
○　git push origin master
git log

切り替え

切り替え練習は下記のアドレスで
https://www.sejuku.net/blog/71457
補足
○　git branch
git push origin develop
git pull origin develop

quiz

バージョン管理の状態を確認するためのコマンド　→
git を　pushする。→
ローカルブランチの一覧を表示する。　→

ターミナル上などでGitコマンドを入力するのは大変ですよね。
そんな時はエイリアス(alias)を使って楽をしましょう〜。

ちなみにエイリアスとは

alias (コマンド) - UNIXなどにおいてコマンドを別名で登録したもの。別名を登録するコマンド名(Wikipediaより)

設定方法

それでは設定方法を解説します。

ターミナル

$ git config --global alias.<ここに省略名> <ここに元のコマンド名>

例：$ git config --global alias.co checkout

上記のように設定します。

ちなみに
--globalを付けることによってユーザーの設定に反映します。（通常はこれで良いかと思います）
--systemにするとPC全体の設定になります。
上記を付けない場合は(git config alias.〜)そのリポジトリのみの設定となります。

優先順位は 【リポジトリ > ユーザー > PC】 になります

もう一つの設定方法

もう一つの設定方法も解説します。

先程のコマンドは結論としてgit configに設定しているので直接git config画面から設定するという方法です。
以下が設定方法です。

ターミナル

$ git config --global --edit
$ git config --system --edit
$ git config --edit (localの設定)

上記を入力することでgit configの設定画面が表示されますのでそこで入力します。
入力したいところで任意のキーを押すもしくは「i」を押すとinsertモードになって入力モードになります。
下の方にスクロールしていくとこんな箇所があります。

ここで直接エイリアスの設定を変更したり削除したり出来ます。

おわりに

いかがでしたでしょうか。
皆さんもGitコマンドにエイリアスを使ってGitの操作をどんどん楽にして行きましょう〜(^o^)

参考にさせて頂きましたサイト

• gitで便利なエイリアス達
• 【git】aliasの設定方法

状況

Githubにてリモートリポジトリを作成
コマンドプロンプトでgit initし、ローカルリポジトリ作成
コミットはできたが、プッシュしたところでpermission deniedエラー

remote: Permission to [使いたいアカウント名]/[プロジェクト名].git denied to [前のアカウント名].

fatal: unable to access 'https://github.com/[使いたいアカウント名]/[プロジェクト名].git/': The requested URL returned error: 403

試したこと

１．以下を叩いてからプッシュ（調べると一番よく出てきた内容）

git remote set-url origin https://[使いたいアカウント名]@github.com/[使いたいアカウント名]/[プロジェクト名].git

２．.git/configを確認
ローカルリポジトリのフォルダに.gitというフォルダが作成されています。
隠しファイル見れるようにしないと見れないかも…？

テキストエディタとかで開いて、userの部分が使いたいアカウントのものになっているか確認

解決

以下を参考にさせていただきました。
https://qiita.com/hiro9/items/19a415ed2349430663b3

汎用資格情報

下記画像gitの行の赤丸部分をクリックするとユーザー名、パスワードの記載があります。

編集をクリックして使いたいアカウントのユーザ名とパスワードを入力

その後コマンドプロンプトに戻ってgit push -u origin masterでプッシュできました。

一度プッシュしたtagは、名前変更・削除してはならない

プッシュしたtag名を削除・変更してはいけない理由は、git tagのmanコマンドの中で説明されている。

manコマンドの内容は、コマンドの使い方を淡々と説明している印象があり、今まであまり読んでこなかった。
しかしgit tagのmanコマンドではとても人間味のある文章が書かれていた。

感情部分だけ要約すると、
「tag名を変更するのは馬鹿げている！！絶対にするなよ！！
それでもやりたいって？じゃあこうやれ！馬鹿げたやり方だけどな！！
それは面倒だって？やるならこれしかないんだよ！（怒）」
という筆者の熱い思いが文章で綴られている。

それでは見ていこう。

manコマンドをみてみる

下記コマンドで該当の記述を読むことが出来る

man git-tag

web上で見たい場合はこちらでも。

原文

該当の記述はこちら

On Re-tagging
What should you do when you tag a wrong commit and you would want to re-tag?
If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you're done.
But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:
1. The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have
"version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.
2. The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn't already published the old one.
However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn't just make them overwrite the old one.
If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you
really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:
Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the fixed tree as X again.
If you got the wrong tag, and want the new one, please delete
the old one and fetch the new one by doing:
git tag -d X
git fetch origin tag X
to get my updated tag.
You can test which tag you have by doing
git rev-parse X
which should return 0123456789abcdef.. if you have the new version.
Sorry for the inconvenience.
Does this seem a bit complicated? It should be. There is no way that it would be correct to just "fix" it automatically. People need to know that their tags might have been changed.

意訳

怒りの部分が分かるように意訳していく。

pushしていないtagは変更して良い

-fオプションを使って名前を付け替えるだけで良い。

pushしたけどtag名を変更したくなった場合

push済みの場合、他の作業者がpushしたtagをみている可能性がある。
その場合出来る方法は2つある。

1.健全なやり方(sane thing)

まずはやらかしたことを認めろ。そして違うタグ名を使え。
（わざわざ「健全な」とつけたり、やらかしたことを最初に認めさせたりと怒りが沸き始めている）
もし同じ名前で新しい内容でtagを作った場合、同じversion Xという名前なのに、人によって違う内容を指している状態ができてしまう。
あなたはversion X.1など別の名前を使いなさい。

2.狂気的なやり方(insane thing)

(もうワードが強い。怒りに溢れている)
あなたがどーしても同じtag名で新しい内容を指したいのであれば、
それも既に他の作業者がpushしたtagを既にみているのにどーしてもやりたいのであれば、
-fオプションでforce pushすれば良い。まるでまだtagをpushしていなかったかのようにね。
(やっても良いと言う割に、節々に嫌味っぽい怒りを感じる)

tagを変更したとしても、他の作業者のtagがあなたの更新で上書かれるわけではない

しかし、Gitはユーザーの見えないところでtagを変更することはしないし、するべきではない。
すなわち、古いtagが既にある状態でgit pullをしても、新しいtagが上書かれることはない。
同じレポジトリの作業者がtag名を「必ず」信頼出来る状態でなければならない。
(manコマンドらしく、知るべき前提情報を淡々と説明してある)

それでも狂気的なやり方をやりたい場合

まず大騒ぎして、他の作業者に自分がやらかしたことを報告し、下記の内容をレポジトリの全ての作業者に大々的に告知しなければならない。
(罪を償え！と言われている気がしてならない)

告知すべき内容

私はやらかしました。
tag Xを新たなバージョンとしてpushしました。
もし間違った(古い)タグを取得してしまい更新する必要がある方は、古いtagを削除し、新しいtagをfetchしてください。
コマンドは下記です。

git tag -d X
git fetch origin tag X

下記コマンドで最新のtagを取得しているか確認することができます。

git rev-parse X

正しければ0123456789abcdefが表示されます。
ご不便をおかけし申し訳ありません。

やり方が複雑だって？やるべきだ！

自動的に「修正」する方法なんて他にない。
（「修正」が強調されているのは、やっていることが修正ではなく「狂気な所業」なので、修正というものばからしい、のニュアンスが入っている）
他の作業者は自分が触っているtagが変更されている可能性があるなら知らされるべきだ。

manコマンドから感じられた怒りと要点まとめ

とりあえず、remoteのtagを変更したらgitメンテナがめっちゃ怒ることは感じられたと思う。
git tagでのベストプラクティスは、

• tagは1度pushしたら変更はしない
• どうしても変えたくなったら別のtag名を新たに付与する

こと。
理由は

• gitの思想的に、tag名によってtagが一意に決定され存在が保証されるべき
• tag変更後他の作業者がpullをしても、tag名の上書きは行われない
• 上書きを行いたかったら、全ての作業者が取得済みのtagを消してfetchし直す必要がある

ことである。

もし「tagを変えたい」とチーム内で相談されたら、
「やれないことはないけどめんどくさいよ。
あと、gitメンテナがめっちゃ怒るよ」
と伝えるようにしよう。

このmanコマンドを書いた人は何者？

この人間味を溢れる記述を書いたのは、なんと日本人エンジニア。
お名前は濱野純さん。
該当のコミットはこちらからgithub上で見れる。

濱野純さんはLinuxの生みの親リーナス・トーバルズから信頼されたGitメンテナであり、Googleのエンジニアである。

濱野 純 (はまの じゅん、英語: Junio C Hamano) は、カリフォルニア在住[1]の日本のソフトウェア工学者（英語版）である。現在はGoogleに勤務している[2]。最初のリリースから2ヶ月後の2005年7月26日からGitのメンテナであることで知られている[3][4]。リーナス・トーバルズは2012年に、Gitが彼にとっての最大の成功の1つとなったのは、濱野がGitの開発において優秀な開発者であることによると認識しており、メンテナとして彼を信頼していると述べた[5]。

引用:wikipediaより https://ja.wikipedia.org/wiki/%E6%BF%B1%E9%87%8E%E7%B4%94

まとめ

gitメンテナの怒りを買わないように、tagは変えずに新しく作ろう！

関連書籍

GitHub実践入門
新卒エンジニア向け課題図書。
結局gitで難しいのはコマンドの扱い方ではなく、git上での他の作業者との円滑なやり取りだったりする。
gitを使ったチームでの開発フローに関して、何かしら読んでから現場に入ってもらえるとスムーズに感じる。

Gitで特定の名前のブランチ群をまとめて消したい時があります。xargsやgrepを使う方法もありますが、ここではgitコマンドのみでできるシンプルな方法をまとめます。

確認環境

• MacBook Pro (16-inch 2019)
• macOS Catalina 10.15.6

方法

例えば名前の頭にdevelop/のついたブランチを消したいとします。
その場合、以下をコマンドラインで実行します。

git branch -D `git branch --list 'develop/*'`

これの原理は簡単で、まず消したいブランチを名前で絞り込み(git branch --list 'develop/*')、それを削除コマンド(git branch -D <削除対象>)へ送っています。

より安全な手順

上記コマンドをそのまま実行すると、もし絞り込みの指定でミスっていた場合、必要なブランチを消してしまう可能性があります。
まずは以下のコマンドを単独で実行して、表示されたブランチを確認し、

git branch --list 'develop/*' # 削除対象を確認

それらが消えてよければ、実際の削除に進むのが良いと思います。

git branch -D `git branch --list 'develop/*'` # 実際の削除

以上です。

参考

Can you delete multiple branches in one command with Git?
https://stackoverflow.com/a/47304256

初めに

この学習記録は自分用にメモを取ったものをそのまま羅列しているだけですので予めご了承ください。

メモ

git はスナップショット　
gitはコミットをたどることで以前の状態に戻せる
ローカルは3つのエリアに分かれている

ローカルリポジトリ
↓ ↑git commit スナップショットを記録
ステージ
↓　　↑git add 　コミットする変更を準備
ワークツリー

ステージの概念ががややこしい。
分かりやすいURL↓↓
https://kray.jp/blog/expound-git-add/

使用したLinuxコマンド

ecoh 書きたい文字 >> ファイル名
.（ファイル名）　隠れフォルダ
mv ファイル 移動先ディレクトリ
mkdir ディレクトリを作成
touch ファイルを作成　
--global PC全体に設定

git init で.gitディレクトリ作成される
.gitディレクトリにほとんどのファイルが入る
コミット数は大きい番号ほど前（親コミット）
*バージョン管理するべきではない情報を.gitignoreに書く

使用したgitコマンド

・git diff ワークツリーとステージとの差分表示
・git diff --staged ステージとリポジトリとの差分表示
・git log commitの履歴を確認
・git log commit -p <ファイル名> ファイルの変更差分　
・git log commit　 -n <コミット数> 表示するコミット数を制限
・git rm <ファイル名＞　or -r<ディレクトリ名> ファイルごと削除
・git rm --cached<ファイル名> リポジトリからだけ消してファイルは残る
・git mv <元のファイル名> <新しいファイル名＞　ワークツリーとステージのファイル名を変更
・git config gitを設定　
・git config --gloabal alias.<エイリアス名> <元のコマンド名>
・git reset HEAD <ファイル名＞　ステージの変更をなかったことに
・git checkout -- <ファイル名> ワークツリー内の変更をなかったことに