- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2022-03-20T11:54:25+00:00","default:admin","admin")
#author("2022-04-11T13:26:51+00:00","default:admin","admin")
*基礎 [#z8cd5b0d]
-[[サル先生のGit入門:https://backlog.com/ja/git-tutorial/]]
-[[“マンガでわかるGit”の記事一覧:https://next.rikunabi.com/journal/tag/webdesign-manga/]]
-[[【連載】マンガでわかるGit～コマンド編～:https://www.r-staffing.co.jp/engineer/archive/category/%E3%83%9E%E3%83%B3%E3%82%AC%E3%83%BBGit]]
**fetch, merge, pull [#q9c11e42]
-[[マンガでわかるGit 第8話「GitHubを使ってみよう push・pull編」:https://next.rikunabi.com/journal/20161209_t12_iq/]]
-[[マンガでわかるGit 9話「pullの正体はfetch＋mergeだった？」:https://next.rikunabi.com/journal/20170120_t12_iq/]]
-fetch
--fetchは、リモートリポジトリから更新内容をダウンロードしてきて、ローカルリポジトリ内のリモート追跡ブランチを更新する
--リモート追跡ブランチ（origin/ナントカ）が更新されるだけ
--この時点ではローカルブランチは更新されていない
-merge
--mergeすることで、はじめてローカルブランチが更新される
-pull
--「fetchしてからmerge」は、開発の中で頻繁に行われる
--fetchとmergeを合わせた機能がpull
*ブランチモデル [#t7072bee]
-[[Gitのブランチモデル(git-flow, GitHub Flow, GitLab Flow)のブランチ名まとめ:https://www.ninton.co.jp/archives/3304]]
-[[Gitブランチモデルの比較と使い分け:https://yukke722.hatenablog.jp/entry/2020/11/06/084720]]
-[[Gitにおけるブランチ戦略について調べてみた:https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea]]
-[[Gitの運用方法の有名な３パターンについての考察:https://kohei.life/git-flows/https://kohei.life/git-flows/]]
-[[キャスレーの社内開発で利用するgitのブランチモデルとかPull Requestの簡単な解説とか:https://www.casleyconsulting.co.jp/blog/engineer/53/]]
-ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン
-ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる
-リモートブランチの名前から、なんのためのブランチかを推測しやすくなる
**Git-flow [#y8040cce]
-[[Git-flow ～Gitのブランチモデルを知る～:https://tracpath.com/bootcamp/learning_git_git_flow.html]]
-[[Git Flowの推奨はもう止めましょう！:https://itnews.org/news_contents/please-stop-recommending-git-flow]]
***masterブランチ [#nbaaf525]
-git-flowでは master ブランチに直接コミットすることはなく、マージを行うだけのブランチになる
-誤って直接コミットしてしまわないように注意
***developブランチ [#nab9cfea]
-develop ブランチは、開発の中心となるブランチ
-開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる
-master ブランチ同様、直接このブランチにコミットすることはないので注意
-リポジトリを新規作成したときに、master ブランチから develop ブランチを切っておく
***featureブランチ [#ua2b196a]
-feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ
-ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる
-ブランチの名前は、変更の内容がすぐに分かるような名称にする
-develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。
***releaseブランチ [#u9d7633a]
-release ブランチは、その名の通り製品をリリースするために使うブランチ
-製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。
-リリース作業が完了したら、master ブランチと develop ブランチにマージして、master ブランチのマージコミットにリリースタグ（バージョンなど）をうちましょう。その後、release ブランチは削除します。
***hotfixブランチ [#z06aab7c]
-製品のリリース後に不具合が見つかった場合は master ブランチから直接 hotfix ブランチを切って緊急の修正を行う
-修正完了後に master ブランチと develop ブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後 hotfix ブランチを削除する
-派生元が master になるだけで、操作的には release ブランチと同様
***supportブランチ（オプション） [#v35ca0e4]
-プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる
-support ブランチでは、旧バージョンの保守とリリースを行う
-サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う
**GitHub Flow [#t1725947]
***masterブランチ [#ee0ac5cf]
-現在の製品のメインブランチ
-常にデプロイ可能な状態
***featureブランチ [#s0fba90a]
-新しい作業を開始するときに、わかりやすい名前のブランチをmasterから分岐
-ローカルでコミットして、同じ名前でリモートにもpush
-フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成
-他のメンバーがレビューして確認したら、masterへマージする
-masterにマージしたらデプロイできる
**GitLab Flow [#h2267557]
**その他 [#rfae5d48]
-[[GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します:https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama]]
*マージ [#n98fd088]
-First-Forward
-Auto-Merge
*ソフトウェア [#m71dd0fa]
**Git [#k7cc0090]
**[[Sourcetree:https://www.sourcetreeapp.com/]] [#b0dc6729]
**GitHub Desktop [#ye565686]
**TortoiseGit [#db69b1c2]
**GitKraken [#a1f81b05]
*書籍 [#ha1b4a9f]
***サルでもわかるGit入門 [#r868af97]
-[[サポートページ:https://book.impress.co.jp/books/1118101032]]
*環境構築 [#hf6e0e72]
**プロキシ [#h4841719]
-会社などプロキシ環境では必要
-[[【mBaaS】 初期設定 ～プロキシ接続をしてgitからcloneする～:https://qiita.com/oonoyosp/items/3877dcb8cf8823f3d9b4]]
**[[Git for Windows:https://gitforwindows.org/]] [#j6013b17]
-[[私家版 Git For Windowsのインストール手順:https://opcdiary.net/technical/programming/%e7%a7%81%e5%ae%b6%e7%89%88-git-for-windows%e3%81%ae%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e6%89%8b%e9%a0%86/]]
*diff [#b5e0c965]
-[[git diff を徹底攻略！よく使う便利オプションまとめ、完全版。:http://www-creators.com/archives/755]]
* gibo [#ub30f2ae]
-[[gibo – .gitignoreの雛形を素早く作成できるコマンドラインツール:http://www.softantenna.com/wp/review/gibo/]]
-インストール
$ brew install gibo
-指定項目のリスト表示
$ gibo -l
-.gitignore 新規作成（macOS, Xcode, Vim の3つを指定）
$ gibo macOS Xcode Vim > .gitignore
-追加
$ gibo Swift >> .gitignore
*Tips [#ya173144]
-[[Gitのリポジトリ（履歴）を初期化する:https://qiita.com/mktshhr/items/578cc5b5aea5b3ed9303]]
-[[ローカルのプロジェクトをGitHubへアップロードする方法:https://qiita.com/devzip8/items/28ac253ea295ad6c2b73]]
*トラブルシューティング [#p378791d]
**SSL certificate problem: Unable to get local issuer certificate [#oe3b83bf]
**Please make sure you have the correct access rights and the repository exists. [#s7042006]
-[[Gitで自分のbitbucketの非公開レポジトリからクローンできなくなった:https://applingo.tokyo/article/3391]]
-[[githubからcloneするときにPermission denied (publickey)エラーが発生する:https://hacknote.jp/archives/14711/]]
--[[ssh-agentを使ってgithubへssh接続する:https://qiita.com/ggg-mzkr/items/fd32e1a6b7353ca52d3c]]
-[[gitでPlease make sure you have the correct access rights and the repository exists. が出た時の対処法:https://qiita.com/GakuNaitou/items/81dbbd3ea6211af71648]]
-[[【解決方法(画像付き)】急に。git pushしたら「Please make sure you have the correct access rights and the repository exists.」:https://kenjimorita.jp/please-make-sure-you-have-the-correct-access-rights-and-the-repository-exists/]]
-[[認証は通っているのにGitでGitHubリモートリポジトリにアクセスすると Permission denied になる問題の原因:https://noraworld.hatenablog.com/entry/fix-that-git-throws-permission-denied]]
-[[【git エラー解決策】Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. が出た時の解決方法:https://tusukuru.hatenablog.com/entry/2018/08/29/021651]]
-[[【git pushエラー】: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. の対処策:https://papa-programing.jp/git-push-error/]]
-[[GitHub解決方法『fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.』Pushできない！:https://shibaemon.com/github-push-fatal/]]
-[[ssh内でgit cloneをした際のpermission deniedを解決する:https://www.furusato-s.co.jp/press/2020/06/22/ssh%E5%86%85%E3%81%A7git-clone%E3%82%92%E3%81%97%E3%81%9F%E9%9A%9B%E3%81%AEpermission-denied%E3%82%92%E8%A7%A3%E6%B1%BA%E3%81%99%E3%82%8B/]]
-[[GitHubにpushやpullできなくなったときの対処法:http://post.tetsuji.jp/2013/11/solution-of-github-io-disabled/]]
***git-upload-pack [#aacd406f]
-[[git for windowsに対してWindows版OpenSSHを使ってリモートからリポジトリのclone/pushする方法:http://tdf.or.jp/d/git-for-windows%E3%81%AB%E5%AF%BE%E3%81%97%E3%81%A6windows%E7%89%88openssh%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%81%8B%E3%82%89%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88/]]
-システムの環境変数に「C:\Program Files\Git\mingw64\bin」を追加して sshd を再起動
***does not appear to be a git repository [#ca777454]
-[[Herokuにpush時にdoes not appear to be a git repository出た時の対処:https://qiita.com/sayama0402/items/e2c9e65786259dc55e11]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
