0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

GitHubでブランチを切ったあとになぜmasterをマージするのかの理由と、macだけで出て解決大変だった Permission denied (publickey). を解決した話

Last updated at Posted at 2020-10-27

Git hubで作業する際に、初学者の僕が疑問に思っていた pull, push, merge をしていく理由について少し理解できたので、備忘録で記載しています。あと、macユーザーですがめちゃくちゃ pull, push, merge ではまったPermission denied (publickey).の解決方法も提示します。

まず、なぜ pull, push, merge なんてややこしいことをたくさんやらないといけないのかということです。今の時代共同作業だったら、google docs みたいにみんなでポンポン同時並行で出来ちゃえばいいのに、最先端のエンジニア領域でこんなめんどくさいことやっているんだろうと疑問に思いました。

まず大前提として master は何の汚れも無い(バグが絶対にないことを期待される)完全体です。

(図でいうと緑の線 出所:https://backlog.com/ja/git-tutorial/stepup/01/)
image.png

なので master が汚れないように、開発されたコード部分を master へ取り込む際に、「検証する人(=レビュアー)」がいます。その検証者がチェックして、OK であれば master に反映されます。

完全体ということで、master は他のブランチを担当している人たちの修正が統合され、どんどん成長していく一方で、ブランチによっては昔に作られたまま長らく放置されたり、独自でプログラミングしてる状況のものがあります。
image.png

そのため、いざ長期に切り離して作っていたブランチを反映させようとすると master 自体がずっと先にいっていますので、「他の人によって更新された膨大な量の変化」を検証者がチェックしなくてはいけなくなります。

「すでにチェックされ、統合された部分の再チェックをしてしまう」工数を省くために、ブランチ担当者が master の現在の状態を merge して、現状の master との差分(=自分が本当に開発した部分)だけを見てもらうようにします。

でこんな話を書いたのは、長らく、macpull, push, merge をしようとしても Permission denied (publickey). にハマって全然できていなかったからです。

windows はないのですが、mac は、キーチェーン登録 をしないといけないようで、その実行をしたら解決しました。

$ ssh-add -K

これをterminalで実行したら、VSCode上からのUI操作からでもPushがうまくいきましたとさ。

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?