Git のバックアップ(No.14)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ | ログイン ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Git へ行く。
  • 1 (2017-04-09 (日) 21:28:04)
  • 2 (2017-05-06 (土) 18:56:11)
  • 3 (2019-01-28 (月) 17:01:12)
  • 4 (2019-03-13 (水) 16:16:40)
  • 5 (2021-06-15 (火) 19:45:16)
  • 6 (2021-06-16 (水) 00:28:31)
  • 7 (2021-06-16 (水) 10:02:26)
  • 8 (2021-06-16 (水) 14:13:09)
  • 9 (2021-12-27 (月) 13:41:28)
  • 10 (2022-02-25 (金) 22:26:00)
  • 11 (2022-03-11 (金) 14:25:20)
  • 12 (2022-03-20 (日) 20:54:25)
  • 13 (2022-04-11 (月) 22:26:51)
  • 14 (2022-04-12 (火) 10:16:39)
  • 15 (2022-04-12 (火) 14:10:35)
  • 16 (2022-04-12 (火) 20:08:33)
  • 17 (2022-04-13 (水) 11:04:35)
  • 18 (2022-04-13 (水) 17:29:15)
  • 19 (2022-04-14 (木) 09:23:15)
  • 20 (2022-04-28 (木) 11:30:07)
  • 21 (2022-05-16 (月) 08:39:31)
  • 22 (2022-05-17 (火) 11:20:35)
  • 23 (2022-05-19 (木) 09:28:01)
  • 24 (2022-06-08 (水) 14:57:00)

---

基礎 †

• サル先生のGit入門

• “マンガでわかるGit”の記事一覧
• 【連載】マンガでわかるGit～コマンド編～

fetch, merge, pull †

• マンガでわかるGit 第8話「GitHubを使ってみよう push・pull編」
• マンガでわかるGit 9話「pullの正体はfetch＋mergeだった？」

• fetch
  • fetchは、リモートリポジトリから更新内容をダウンロードしてきて、ローカルリポジトリ内のリモート追跡ブランチを更新する
  • リモート追跡ブランチ（origin/ナントカ）が更新されるだけ
  • この時点ではローカルブランチは更新されていない
• merge
  • mergeすることで、はじめてローカルブランチが更新される
• pull
  • 「fetchしてからmerge」は、開発の中で頻繁に行われる
  • fetchとmergeを合わせた機能がpull

ブランチモデル †

• 【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう
• Gitのブランチモデル(git-flow, GitHub Flow, GitLab Flow)のブランチ名まとめ
• Gitブランチモデルの比較と使い分け
• Gitにおけるブランチ戦略について調べてみた
• Gitの運用方法の有名な３パターンについての考察
• キャスレーの社内開発で利用するgitのブランチモデルとかPull Requestの簡単な解説とか

• ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン
• ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる
• リモートブランチの名前から、なんのためのブランチかを推測しやすくなる

Git-flow †

• Git-flow ～Gitのブランチモデルを知る～
• Git Flowの推奨はもう止めましょう！

masterブランチ †

• git-flowでは master ブランチに直接コミットすることはなく、マージを行うだけのブランチになる
• 誤って直接コミットしてしまわないように注意

developブランチ †

• develop ブランチは、開発の中心となるブランチ
• 開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる
• master ブランチ同様、直接このブランチにコミットすることはないので注意
• リポジトリを新規作成したときに、master ブランチから develop ブランチを切っておく

featureブランチ †

• feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ
• ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる
• ブランチの名前は、変更の内容がすぐに分かるような名称にする
• develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。

releaseブランチ †

• release ブランチは、その名の通り製品をリリースするために使うブランチ
• 製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。
• リリース作業が完了したら、master ブランチと develop ブランチにマージして、master ブランチのマージコミットにリリースタグ（バージョンなど）をうちましょう。その後、release ブランチは削除します。

hotfixブランチ †

• 製品のリリース後に不具合が見つかった場合は master ブランチから直接 hotfix ブランチを切って緊急の修正を行う
• 修正完了後に master ブランチと develop ブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後 hotfix ブランチを削除する
• 派生元が master になるだけで、操作的には release ブランチと同様

supportブランチ（オプション） †

• プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる
• support ブランチでは、旧バージョンの保守とリリースを行う
• サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う

GitHub Flow †

• GitHub Flowとは

masterブランチ †

• 現在の製品のメインブランチ
• 常にデプロイ可能な状態

featureブランチ †

• 新しい作業を開始するときに、わかりやすい名前のブランチをmasterから分岐
• ローカルでコミットして、同じ名前でリモートにもpush
• フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成
• 他のメンバーがレビューして確認したら、masterへマージする
• masterにマージしたらデプロイできる

GitLab Flow †

その他 †

• GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します

マージ †

• First-Forward
• Auto-Merge

ソフトウェア †

Git †

Sourcetree †

GitHub Desktop †

TortoiseGit? †

GitKraken? †

書籍 †

サルでもわかるGit入門 †

• サポートページ

環境構築 †

プロキシ †

• 会社などプロキシ環境では必要

• 【mBaaS】 初期設定　～プロキシ接続をしてgitからcloneする～

Git for Windows †

• 私家版 Git For Windowsのインストール手順

diff †

• git diff を徹底攻略！よく使う便利オプションまとめ、完全版。

gibo †

• gibo – .gitignoreの雛形を素早く作成できるコマンドラインツール

• インストール

  $ brew install gibo
  

• 指定項目のリスト表示

  $ gibo -l

• .gitignore 新規作成（macOS, Xcode, Vim の3つを指定）

  $ gibo macOS Xcode Vim > .gitignore

• 追加

  $ gibo Swift >> .gitignore

Tips †

• Gitのリポジトリ（履歴）を初期化する
• ローカルのプロジェクトをGitHubへアップロードする方法

トラブルシューティング †

detached HEAD †

• 第19話　detached HEAD 状態って何？ブランチがない状態を解決する方法　【連載】マンガでわかるGit～コマンド編～
• 【Git】detached HEADは友達。元に戻す方法や使い方(detached HEADとは何か？の意味を理解して焦らず対応)

SSL certificate problem: Unable to get local issuer certificate †

Please make sure you have the correct access rights and the repository exists. †

• Gitで自分のbitbucketの非公開レポジトリからクローンできなくなった

• githubからcloneするときにPermission denied (publickey)エラーが発生する
  • ssh-agentを使ってgithubへssh接続する

• gitでPlease make sure you have the correct access rights and the repository exists. が出た時の対処法
• 【解決方法(画像付き)】急に。git pushしたら「Please make sure you have the correct access rights and the repository exists.」
• 認証は通っているのにGitでGitHubリモートリポジトリにアクセスすると 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. が出た時の解決方法
• 【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. の対処策
• GitHub解決方法『fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.』Pushできない！
• ssh内でgit cloneをした際のpermission deniedを解決する
• GitHubにpushやpullできなくなったときの対処法

git-upload-pack †

• git for windowsに対してWindows版OpenSSHを使ってリモートからリポジトリのclone/pushする方法

• システムの環境変数に「C:\Program Files\Git\mingw64\bin」を追加して sshd を再起動

does not appear to be a git repository †

• Herokuにpush時にdoes not appear to be a git repository出た時の対処

     

Site admin: anonymous

PukiWiki 1.5.1 © 2001-2016 PukiWiki Development Team. Powered by PHP 5.6.99-hhvm. HTML convert time: 0.021 sec.