WindowsユーザーでGitのクライアントツールとしてSourcetreeを使用して、GitHubとBitbucketのリポジトリと接続する人向けの初期設定手順です。

Gitについて、Sourcetreeの内蔵Gitを使用する手もありますが、コマンドプロンプトでgitコマンドが使えなかったり、Sourcetreeの起動も遅くなる(らしい)ので、Git for windwosをインストールして、SourcetreeではシステムGitを使用する設定を紹介したいと思います。

手順概要としては以下のとおりです。

1. Git for Windows, Sourcetreeのインストール
2. sshキーの生成とGit Bashでの読み込み
3. Sourcetreeでのsshキーの読み込み
4. GitHub, Bitbucketでsshキーの登録

Git for windowsのインストール

Git for windows公式サイトからインストーラをダウンロードし、ダウンロードしたインストーラを実行します。

インストーラのデフォルト設定のままでもいいと思いますが、私の設定、また、個人的に設定を変更した方がいいと思う部分について、記載したいと思います。個人的に設定を変更したほうがいいと思っている箇所については【変更推奨】という印を付けています。

• インストールするコンポーネントの設定画面
  

  • [Additional icons]のチェックを外す
    • Git Bashは基本的に、Sourcetreeを経由して使用するので、Git Bashへのショートカットを作成しないようにした
  • [Windows Explorer integration]のチェックを外す
    • Explorerからgitを使用することもないのでチェックは外した

• デフォルトのエディタ設定
  

  • サクラエディタを設定
    • コミットメッセージ等を編集するときに使用するエディタの設定。テキストを簡単に修正することしかないので、シンプルかつ起動が早いサクラエディタを設定しています。好みのエディタを設定すればいいと思います

• 改行コードの変換設定
  

  • 【変更推奨】[Checkout as-is, commit Unix-style line endings]を選択
    • Dockerを使用する場合などで改行コードがLF→CRLFに変換されると起動しなくなったりするので、チェックアウト時は改行コードの自動変換がされない設定にします
    • Windowsでファイルを作成したとき、改行コードがCRLFになることが多いのですが、リポジトリではLFで管理したいので、改行コードLFに変換するようにします（Gitでは基本はLFで保存することが推奨されている）

SourceTreeのインストール

Sourcetree公式よりインストーラのダウンロードし、ダウンロードしたインストーラを実行します。
インストール時の注意点は以下のとおりです。

• 途中で、Bitbucketのログインが求められたら、Bitbucketのアカウントを作成し、ログインします
• Mercuialは使わないのでインストールしなくていいです
• SSHキーを読み込ませるか聞かれたら、[いいえ]を選択してください

sshキーの作成と、Git bashにsshキーの登録

以前sshキーを作成している場合は、ホームディレクトリ直下の.sshディレクトリにid_rsa, id_rsa.pub, id_rsa.ppkファイル等がある場合があります。
今回紹介する手順では、id_rsa, id_rsa.pub, id_rsa.ppkファイルを作成しますので、ファイル名の変更、または.sshディレクトリのディレクトリ名の変更、または生成するファイル名を別の名前で保存し、今回の手順で適宜読み替えて作業を進めてください。

1. Git Bashを開き、「ssh-keygen」コマンドを発行。sshキーのファイル名を聞かれますが、デフォルトのままでいいと思います。デフォルトのままにする場合は、何も入力せずにEnterキーを打ちます。

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/mongol/.ssh/id_rsa):
Created directory '/c/Users/mongol/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Users/mongol/.ssh/id_rsa.
Your public key has been saved in /c/Users/mongol/.ssh/id_rsa.pub.
The key fingerprint is: 
SHA256:(以下省略)

1. そのままGit Bashで「ls .ssh -l」コマンドを発行し、id_rsaとid_rsa.pubの2ファイルが生成されたことを確認します

$ ls ~/.ssh -l
total 5
-rw-r--r-- 1 mongol 197609 2602 12月 22 14:41 id_rsa
-rw-r--r-- 1 mongol 197609  572 12月 22 14:41 id_rsa.pub

1. そのままGit Bashを使用して、eval $(ssh-agent)コマンドを発行し、ssh-agentを起動します。ssh-add ~/.ssh/id_rsaコマンドを発行し、sshキーを登録します。

$ eval $(ssh-agent)
Agent pid 9700
$ ssh-add ~/.ssh/id_rsa
Identity added: /c/Users/mongol/.ssh/id_rsa (mongol@mongol-note-pc)

これでGit Bashにsshキーが登録できました。

SourceTreeでのSSHキー読み込み

ssh-keygenで生成したsshキーはOpenSSH形式ですが、SourceTreeではPuTTyを利用してssh通信を行うため、PuTTy形式のsshキーが必要になります。
PuTTYを使ってPuTTY形式のsshの秘密鍵(プライペートキー)を作成して読み込ませる必要があります。

1. PuTTy形式のSSHプライベートキーの作成します。Sourcetreeを開いて、ツールバーの[ツール] > [SSHキーの作成/インポート]をクリックします。PuTTY Key Generatorウィンドウが開きます
2. [Actions]の[Load]ボタンをクリックします。開いたファイル選択ダイアログでは.ppkファイルのみに絞られているので、All Filesにして、id_rsaを選択します。
3. 警告が出ますが、OKをクリックします。
   
4. [Actions]の[Save private key]ボタンをクリックします。passphraseなしで保存していいかという旨の警告が出てきますので、OKボタンをクリックします。id_rsa.ppkというファイル名でPuTTY形式の秘密鍵を保存します。
   
5. タスクトレイから「Pageagent」を右クリックし、「Add Key」を選択します
   
6. 同じくタスクトレイから「Pageagent」を右クリックし、「View Keys」を選択。読み込まれていることを確認します
   

GitHubとBitbucketに公開キーを登録

1. GitHubに公開キーを追加

   1. GitHubを開き、右上の自分のアイコンをクリックし、[Settings]を選択します
   2. 左のナビゲーションバーから[SSH and GPG keys]を選択し、SSH keysの画面が開くので、[New SSH key]ボタンをクリックします。
   3. TitleにSSHキーの登録名を任意に設定し(端末名が分かるようにしておくと良い)、keyに.sshフォルダのid_rsa.pubの中身をコピペします。[Add SSH key]ボタンをクリックします

2. Bitbucketに公開キーを追加

   1. Bitbucketを開き、左下の自分のアイコンをクリックし、[Bitbucket settings]を選択します
   2. 左のナビゲーションバーから[SSH鍵]を選択し、SSH 鍵の画面が開くので、[鍵を追加]ボタンをクリックします。
   3. LabelにSSHキーの登録名を任意に設定し(端末名が分かるようにしておくと良い)、keyに.sshフォルダのid_rsa.pubの中身をコピペします。[鍵を追加]ボタンをクリックします

TL;DR

オートデプロイ実装するついでにgit-flow導入を検討中。
リリースブランチで最終ステージングテストするよ。

背景

手動デプロイからオートデプロイに切り替えるプロジェクトを担当しています。
オートデプロイを実現するにあたって業務フローを見直していたところ、Gitの運用も今のままだときついのでGit-flowに変えましょうという話になりました。

Git-flowとは？

Gitの運用に関するベストプラクティスの一つです。

提唱元はこちらです。

A successful Git branching model
https://nvie.com/posts/a-successful-git-branching-model/

日本語だと以下の記事が大変良くまとまっています（すばらしい！）

gitの運用ワークフローのメモ（git-flow、github flow等）
https://qiita.com/ta-ke-no-bu/items/a9854deb61419a0d64c7

Gitにある程度慣れたユーザは「ブランチをどう切ってどうマージするか？」という問題にぶち当たると思います。
そしてこれには正解がない。業務上のコード管理をどうするかという問題そのものだから。

でもとりあえず悩んだらベストプラクティスから選択してそれに沿うのは賢いやり方です。
料理の素人はレシピ通りに作りましょう。オラそこ隠し味入れてんじゃねぇ！

現在のGit運用

ざっくりこんな感じの運用をしてます。

• master: 本番コード
• pj_xxx/dev: プロジェクトごとの開発ブランチ
• pj_xxx/nyaaan: プロジェクトごとの作業ブランチ
• issue/zzz, feature/heyhey, hotfix/vivivi, bugfix/owata: その他有象無象

なんか細かい命名ルールあったけど忘れた。（オレオレルールだと普及も大変です）
trunkブランチもかつてありましたが滅ぼしました。（お察しの通りかつてsvn管理でした）
正直master以外管理されていないです。

リリース時には本番環境よりmasterコードが先行する形になります。

現運用の課題点

ざっくりこんな感じ。

1. コンフリクト問題

• 開発ブランチ間でコンフリクトしたときに泣ける
• 開発ブランチがmasterちゃんと追従していない場合がある
• 直前のバグ修正の影響で開発ブランチがコンフリクトしてマージできない
• 直前のバグ修正を取り込み漏れでmasterのUTコケてる

2. リリース中断時の問題

• リリース中に問題が発覚して撤退した場合masterブランチにrevertを積む必要がある

3. 不思議ちゃん

• masterに積まれてるけどデプロイされてない変更があるぞ？

特に今回問題を感じたのは１，２です。（3は自動デプロイしようね）
オートデプロイに乗せるにあたって先にmasterに積んでそれを起動としてしまうと、巻き戻しが発生したときに本質でない変更コミットがガンガン積まれます。

それを避けるためにはmasterは本番変更よりもあとに更新。
共通のdevelopブランチでコンフリクト解決やリリース直前テストをしておきたい。

Git-flow選択の理由

現運用がほとんどまともにブランチ管理していないので、ベストプラクティス輸入して当てはめるのが一番早いです。
詳細にブランチ運用を定義するための情報も得られてないですし。

他にGitHubFlowとか色々あるのですが、現状うちのプロジェクト進行を鑑みるに、最終調整のdevelopブランチは不可欠ということでgit-flowベースで設計を進めることにしました。（GitHubFlowの方は比較的少人数向きかな？）

Git-flowのデプロイパイプラインへの当てはめ

元記事の以下のイラストをベースに説明していきます。

A successful Git branching modelより引用

メインブランチ(develop/master)

Git-flowにおいて永続するブランチはこの２つのみです。
masterよりdevelopが先行して、デプロイ直後に追いつく形になります。
（主にやりたかったのがこれ）

この２つのブランチは更新を検知してUTを回して方針です。

リリースブランチ(release/x.y.z)

リリース作業の間だけ存在するブランチ。
developから派生して、デプロイ後にdevelopとmasterにマージされます。
本番環境にはこのブランチをデプロイすることになります。最終クッション。

作成を検知してステージング環境に自動デプロイしてステージングテストができるようにします。
軽微なバグの修正はここにコミットが積まれます。（深刻なバグ？撤退しろ）

２つ以上同時に存在する予定は無いもののバージョン番号のブランチ名つけておいたほうが無難でしょう。

Featuresブランチ

その他諸々の変更を積むブランチ。プロジェクトの開発ブランチもこの一部。
developから派生してdevelopにマージします。

Hotdixesブランチ(hotfix/x.y.z)

緊急用。上記のブランチルールによる運用回してられないような危機的状況向けです。
masterから直接派生してmasterとdevelopにマージされます。

実際の運用としては、本番環境を直接触って後付でコミット積む形になると思います。
このブランチ採用すべきか議論を呼んだんですが、結果入れることにしました。

理由としては以下の２点です。

1. デプロイパイプラインは初めは安定しないと思われる
2. うちのサービス特性上、一刻を争う危機的状況は起こり得る

1はともかく2の理由があるので廃止することはなさそうです。

まとめ

• オートデプロイするうえでgitの運用はちゃんとしような
• 迷ったらベストプラクティス使っとけ
• 開発規模でかいならgit-flowおすすめやで
• ステージングテストはリリースブランチでしよう

間違えてgit commit -a --amendしてしまい、
一つ前のcommitに入れたくない変更が入ってしまった。
git resetで戻そうと思い、git logで履歴を確認するが
先頭がamendしたcommitになっておりresetできなくて困った。

解決方法
git reflogでHEADの変更履歴がみれるので、
amendする前の状態にresetすることができる。
resetしたあと普通にgit commit -aすることで解決した。

間違えてgit commit -a --amendしてしまい、
一つ前のcommitに入れたくない変更が入ってしまった。
git resetで戻そうと思い、git logで履歴を確認するが
先頭がamendしたcommitになっておりresetできなくて困った。

解決方法
git reflogでHEADの変更履歴がみれるので、
amendする前の状態にresetすることができる。
resetしたあと普通にgit commit -aすることで解決した。

（追記）
下記の問題はhusky v4.0.7で修正された様子。

---

Node.jsで開発中のリポジトリで、気付いたらgit pushができなくなっていた。

$ git push origin master
stdin is not a tty
error: failed to push some refs to 'https://github.com/xxxxx/xxxxx.git'

gitのバージョンは以下の通り。

$ git --version
git version 2.24.1.windows.2

• エラーが起きたrepoでcommitやpull→できる
• エラーが起きたrepoをgithubの新規リモートrepoにpush→できない
• エラーが起きたrepoをbitbucketの新規リモートrepoにpush→できない
• 空のrepoを新規作成してgithubの新規リモートrepoにpush→できる
• 空のrepoを新規作成し、エラーが起きたrepoの.gitフォルダ以外をすべてコピーしてpush→できる

以上の現象から.gitフォルダ内の破損かと思ったが、エラーになるのがpushだけというのが気になる。また、エラーメッセージもなんかスクリプトっぽい。そういえば、プロジェクトにhuskyを追加していたことを思い出す。

package.json（抜粋）

"husky": "^4.0.6"

.git/hooksを確認し、huskyによって追加されたpre-pushスクリプトをpre-push.bakにリネームして無効化してみると、pushできるようになった。

huskyのreleaseページを確認すると、つい最近に破壊的変更を含むメジャーバージョンアップが行われたらしく、そこから毎日のようにバグ修正版がリリースされている（執筆時点）。まだあまり安定していないのかもしれない。

検索したら同じ問題のissueもすでにあったので、そのうち直ると思われる。
[4.0.0 | Git Bash | Windows 10] stdin is not a tty

自分はpre-pushhookを使っていないし、とりあえず今は無効化しておくことにした。
pre-pushを使いたい場合はhuskyのバージョンを3.1.0系に下げればいいらしい。

はじめに

新しく会社に入社する人に向けた Git および Github の勉強会をすることになったので、重要なポイントを確認するために下記の本を読みました。
その時に話をしたいと思うことをいくつかまとめたいと思い投稿することにしました。

Github については本でもまとめられていたり、他の人がまとめられていたりするので、
"Pull Request の送る方法" の Backlog 版を書きました。参考にしていただけると嬉しいです。

• Github実践入門
  • https://www.amazon.co.jp/GitHub%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-Pull-Request%E3%81%AB%E3%82%88%E3%82%8B%E9%96%8B%E7%99%BA%E3%81%AE%E5%A4%89%E9%9D%A9-PRESS-plus/dp/477416366X

Pull Request

概要

ソフトウェア自体のバグを見つけて修正したコードを管理者に教えてあげること。
Pull Request をソフトウェアの管理者が承認すると、そのソフトウェア自体に修正したコードが反映されます。

この仕組みを用いることでオープンソースとして開発が進められ、IT技術の進歩の早さはこの仕組みがあるからと言われています。

全体のフロー

Pull Request を送るまでの全体のフローを下にまとめました。
上から順に作業していくことで、Pull Request を送ることができます。

1. リモートブランチから自分の開発環境へ Clone
2. 自分の開発環境にてトピックブランチの作成 Branch
3. 作成したトピックブランチにてコードの修正
4. 修正した内容を Commit
5. リモートブランチの作成 & Push
6. Pull Request を送る

リモートブランチから自分の開発環境へ Clone

自分のリポジトリのリモートブランチから自分の開発環境へ Clone します。

$ git clone ${修正を加えたいコードのリポジトリリンク}

自分の開発環境にてトピックブランチの作成 Branch

自分の開発環境にてトピックブランチの作成（Branch）します。

• トピックブランチとは
  • 1つのトピック（テーマ・機能）のコーディングをするためのブランチ（複数のテーマについては扱わない）

// ブランチを確認（-aオプションをつけることでリモートリポジトリのブランチも確認できる。）
$ git branch -a

// ${作成するブランチ名} を master ブランチを元としてコピーし、${作成するブランチ名}へ作業ブランチを移行する。
// master はローカルリポジトリのブランチ名
$ git checkout -b ${作成するブランチ名} master

// ブランチを確認（-aオプションをつけることでリモートリポジトリのブランチも確認できる。）
$ git branch -a

作成したトピックブランチにてコードの修正

作成したトピックブランチにてコードの修正します。
ここは修正内容によって異なるかと思うので、各自修正を加えてください。

修正した内容を Commit

修正した内容を Commit します。

// 変更内容を確認
$ git diff

$ git add .
$ git commit -m "Add Function"

リモートブランチの作成 & Push

リモートブランチを作成し、そのリモートブランチへ Push します。

$ git push origin ${作成するリモートブランチ名}

Pull Request を送る（Backlog版）

上記の準備が終わったらようやく Pull Request を送ることができます。
慣れたら大変な作業ではないので、覚えるまでは根気よくやってください。

リモートブランチの作成 & Push の時の ${作成するリモートブランチ名} をここでは work とします。

画像付きで説明します。

Backlog の Git の画面を開いて、ブランチタブを開くと、push したブランチが追加されていることが確認できます。
次に、表のworkの行のプルリクエストの追加ボタンを押します。

プルリクエストタブに①のマークがつきますので、プルリクエストラブをクリックします。

すると、先ほど追加したworkブランチがプルリクエストとして追加されていることがわかります。
PullRequest を送る方法（Backlog版）としては以上になります。

まとめ

Backlog 版として記事をまとめましたが、Pull Requestを送る全体的なフローに変わりはありません。
Github と Backlog で UI に差があることから少し操作方法に差があるだけですが、この記事をみて誰かの役に立てば嬉しく思います。