元茹でガエルなエンジニアの記録

ちょっとやってみたことや考えたことなどを不定期に書き残していきます

「かなでもの」の杉無垢材デスクが気に入った

コロナ以降、在宅勤務がメインになったので、仕事スペースとしてデスクを新調した。 どうせならノートパソコンとiPadを同時に使えるようにしたかったので、かなり大きめのデスクにしました。

以前、私の尊敬する方が購入していたのを見て以来ずっと気になっていた“かなでもの”さんで購入しました。

f:id:jiig999:20210130114730j:plain 届いた状態。二階まで一人で運ぶのは少し気合いがいりました。 f:id:jiig999:20210130114716j:plain サイズは追加料金無しで指定可能なのですが、僕はデカい作業場所を確保したかったので、思い切って幅170cm、奥行き80cmにしました。 さすがにでかいです。

f:id:jiig999:20210130114749j:plain 杉無垢材のやつを選びました。木目が良い感じです。 f:id:jiig999:20210130114727j:plain 裏面には、脚を固定するためのネジ穴があいています。 f:id:jiig999:20210130114720j:plain 脚はスクエアタイプにしました。シンプルですが格好いい。 f:id:jiig999:20210130114733j:plain 自分で取り付けます。簡単です。 f:id:jiig999:20210130114736j:plain こんな感じ。

f:id:jiig999:20210130114724j:plain 完成。 とても気に入っています。仕事しながらも気がつけば机を撫でて手触りを楽しんでいます。 大満足の一品です。

デスクは広いに限る。 次はイスが欲しくなってきた。。。

踏み台経由でAWS API GatewayのプライベートAPIにアクセスする方法

AWS API GatewayでプライベートAPIというのが作れます。VPCからしか呼び出せないので、リソースポリシーをきちんと設定することで、内部用途でのみ利用する(パブリックに公開しない)APIを実現することができます。

今回はこのプライベートAPIを踏み台のEC2経由で呼び出す場合のやりかたについて書きたいと思います。 (踏み台サーバーにsshログインして、そこからcurlコマンドなどでAPIを呼び出せることは確認済みとします)

今回の構成

以下のような構成だと仮定します。

  • プライベートAPIのエンドポイント:https://abcde.execute-api.ap-northeast-1.amazonaws.com/v1/users
  • 踏み台サーバーのIP:13.xxx.yyy.zzz

発生した課題

踏み台を使った接続でよくやるのは、SSHローカルフォワード設定をしてSSHトンネル接続を使うやり方だと思います。

しかし、プライベートAPI呼び出しのときにはこのやり方ではうまくいきませんでした。 プライベートAPIhttpsで接続するので、サーバー証明書のCN(Common Name)やSANs(Subject Alternative Names)とリクエスト宛先のurlと一致している必要があります。 ローカルフォワードを使うと、クライアントからはhttps://localhost:8888/path/to/resourceみたいな形式で呼び出すことになるため、localhostというホスト名が証明書と一致せずにhttps接続できずにエラーとなります。

リバースプロキシをVPC内に用意して、リパプロとプライベートAPI間をhttpsで通信させることでも回避できそうですが、そのためだけにリバースプロキシを立てたくもありません。 そこで今回はSSHのダイナミック転送を使い、プライベートAPIのリクエストは、SOCKSプロキシ経由で通信することで解決しました。

SOCKSプロキシを利用してリクエストを送信する

SSH接続ではダイナミック転送という機能を使うことができます。ダイナミック転送を使うと、sshクライアントはSOCKSプロキシとして動作します。SOCKSプロキシを経由した通信では、指定されたエンドポイント(今回はプライベートAPI)にはsshサーバー側から接続に行きます。このため、VPCからしか呼び出せないプライベートAPIを呼び出すことができます。かつ、呼び出し元のリクエストURLもプライベートAPIのエンドポイントを指定しているので、課題で書いたようなホスト名の不一致によるエラーも起きません、

~/.ssh/configの例

Host bastion
    Hostname 13.xxx.yyy.zzz
    Port 22
    User ec2-user
    IdentityFile ~/.ssh/id_rsa
    DynamicForward 9999

DynamicForwardの設定が重要です。LocalForwardではなく、DynamicForwadを使います。
このSSH設定で、踏み台とのコネクションを確立します。
すると、DynamicForwardで指定したポート番号がSOCKSプロキシとして動作してくれるので、各ツールなどでそれぞれSOCKSプロキシを指定すれば、プライベートAPIを実行することができます。

curlコマンドの場合の実行例

$ curl --proxy socks5h://localhost:9999 https://abcde.execute-api.ap-northeast-1.amazonaws.com/v1/users

※プロキシとしてsocks5h://〜で指定しています。 SOCKSプロキシはデフォルトではDNS名前解決をクライアント側で行ってからプロキシに渡す動きとなります。しかし、プライベートAPIVPC内からでないと名前解決できないので、名前解決をSOCKSプロキシ側で行うようにオプション指定してやる必要があるので注意してください。 curlの場合、socks5h://と指定することで名前解決をプロキシ側で行ってくれます。(socks5://だと、クライアント側で名前解決してからプロキシに渡す)

ブラウザ用にプロキシ構成ファイルを準備する

今回はブラウザでも動くようにしたいので、FireFoxに読み込ませるプロキシ構成ファイルを用意します。 Chromeなど他のブラウザでも対応可能ですが、以下の理由によりFireFoxを使うことにしました。

  • FireFoxだとシステムの設定とは独立してプロキシ設定をカスタマイズできる(pacファイルを指定する)
  • Chromeは普段使っているので、設定変更したくない

以下の内容でファイルを作成し、bastion_proxy.pacと名前を付けて保存する。ファイル名は任意だが、拡張子は.pacとしておく

function FindProxyForURL(url, host)
{
  // プライベートAPIのDNS名のときはSOCKSプロキシを使う
  if (host === "abcde.execute-api.ap-northeast-1.amazonaws.com") {
    return "SOCKS5 127.0.0.1:9999";
  }

  // 通常はプロキシを使わない
  return "DIRECT";
}

このプロキシ構成ファイルの中で、宛先ホストがプライベートAPIのときは、SOCKSプロキシを使用するように記述している。

  • host===のところは、プライベートAPIDNS名に応じて変更・追加する
  • SOCKS5のところは、localhost + SSH接続でDynamicForward指定したポート番号を指定する

このファイルを、どこでも良いので任意のフォルダに置く(C:¥work¥bastion_proxy.pac など)

FireFoxを開き、メニュー>オプションを開く画面を下にスクロールして、ネットワーク設定>「接続設定」を開く【インターネット接続】画面で以下のとおり設定する以上で準備OK。

f:id:jiig999:20200713160027p:plain
FireFoxの設定

  • ②ファイルパスの指定は、file://で開始する必要があるので注意
  • ③SOCKSプロキシでは通常は名前解決をローカルで行ってから、SOCKSプロキシに渡す挙動になる。しかし、プライベートAPI場合はVPC内からでないと名前解決できないため、ここにチェックを入れる。これにより、SOCKSプロキシ側(=VPC内)で名前解決が行われる。

APIの呼び出し

あとは、ブラウザからプライベートAPIを使用しているサイトを開けばOK! プライベートAPIの呼び出しだけがSOCKSプロキシを利用して通信が行われます。

読書記録2

読書記録の続き

最近読んだ本と感想をメモしておきます。

 

働き方、キャリアに関するもの2冊。
このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

 

どちらも、転職を考えていなくても読んだ方が良い。社内でのキャリア設計にも役立つし、仕事に対する心構えや視座を考え直すきっかけになる。そうなると結果的に今の仕事における動き方やあり方もより良くなると感じた。

正しいものを正しくつくる
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
 

前著のカイゼンジャーニーが面白かったし、著者の市谷さんの考え方など非常に共感できるので、購入。

たんなるアジャイル開発の話ではなく、新規事業立ち上げのプロセスとして教科書になり得る。ITを軸にした新規事業を推進しているなら必読。自分なりに辿り着いた新規事業開発の流れとほぼ同じプロセスになっていたが、リーンスタートアップアジャイル開発の本質を考えていくとやはりこういうことだね、という感じ。

 

ビジネスモデルナビゲーター
ビジネスモデル・ナビゲーター

ビジネスモデル・ナビゲーター

  • 作者: オリヴァー・ガスマン,カロリン・フランケンバーガー,ミハエラ・チック,渡邊哲,森田寿
  • 出版社/メーカー: 翔泳社
  • 発売日: 2016/10/04
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る
 

研修を受講した流れで購入。字がつまっていて読みづらかった記憶しか無い。。

いろんなビジネスモデルを知っておくのには良い。

 

プリンシプルオブプログラミング

久しぶりにこれ系の技術書を買った。最近はコード書くことも少し増えたので、購入。いろんな本などに記載されているプログラミングのコツ、良いプログラミングのために気をつけたいことを知ることができ、おすすめ。

 

ソフトウェア・ファースト
ソフトウェア・ファースト

ソフトウェア・ファースト

 

とてもオススメできる。著者の方が、「当たり前のことしか書いていないし、周りからもそう言われた。なので、この本が売れるようだと日本企業はヤバいと思います」と言っていたのが印象的。

これからの企業に求められるソフトウェアに対する姿勢が分かりやすく書かれている。自分が以前から感じていたことや思っていた課題感を、文書にまとめてくれているので、ソフトウェア開発のありかたを考え直して欲しい人に説明するときに、この本を参考にさせて頂いている。

 

イシューからはじめよ

今さらながら、読みました。

課題解決とかロジカルシンキングのようなことを学んだことのない人にはとてもオススメ。すでにある程度体得している人には、新しく得られることは少ないかも知れない。ただ、、それでもポイントポイントで、筆者ならではのコツだったり思考の整理方法が散りばめられており,読んで損は無いと思う。

 

AWSでのマルチアカウントを攻略する

※書きかけの記事でしたが、完全に仕上げきる前に、ControlTowerが東京リージョンでローンチされたのでニーズは無くなったかも知れません。。。※

AWSを使い込んでいくと、開発案件ごとや環境ごと、技術検証や学習用のラボ環境など、複数のアカウントを使いわけたくなります。というか、分けることが推奨されています。 そんなマルチアカウント環境を構築するにあたり、いろいろ情報が散らばって存在しているので、整理しておくことにしました。

とても参考にさせて頂いたサイト

15分で教えるAWSの複数アカウント管理 - Qiita

Organizationsでイチから頑張るか、ControlTowerを使うか

マルチアカウント環境構築にあたり、ControlTowerの採用を考えた。マルチアカウント環境に必要な一式やセキュリティ対策のサービスとルール含めて一括構築してくれて、マルチアカウントの全リージョンを統合してダッシュボード化までできる。 本当はスゴくスゴく使いたかったのですが、東京リージョンが未対応だったので採用を見送り、自力で頑張ることにしました。

※ 2020.06追記 ControlTowerが既存のOrganizationsに対してあとから有効にできるようになりました。あとは東京リージョンに対応されれば移行しようと考えています。

※2021.04 さらに追記 しばらく仕事上でAWSから離れていたのですが、気付いたらControlTowerが東京リージョンで利用可能になっていました!→ https://aws.amazon.com/jp/blogs/news/aws-control-tower-tokyo/ すなおにこちらを利用するのが楽で良いと思います。

ControlTowerの対応リージョンとは何か

東京リージョン未対応って、結局何が出来て何が出来ないのかよく分からなかったので、実際にアカウント作って確かめました。

ControlTowerを使う場合、ControlTower自体が使ういくつかのサービスや監査ログのS3をどのリージョンに構築するか、という意味でリージョンを決める必要があります。 ここで、東京リージョンは選べないという事になります。 まあこれだけならControlTowerをバージニアとかで立ち上げて使えばいいか、と考えていました。しかし、大事なのは次。 ControlTowerを開始すると、AWS Configの必須ルールなどが適用されるのですが、これが東京リージョン含む"未対応リージョン"には展開されません。 これはツラい。というか使う意味が無くなった。 というわけでチマチマと自分で構築することにしました。修羅の道です。

このへん、AWSさんにはもっと頑張って欲しい。正直、プロダクト単位で環境を分離したいときにわざわざマルチアカウントにしないといけないのが、そもそもいけてない。ここだけはAzureのほうが使いやすい。確かGCPも一つのアカウントで複数の独立したクラウド管理できるし。AWSさん、なんとかなりませんか。頼みます。

アカウント統制やセキュリティ対策観点で使いたいサービス

  • Organizations
  • GuardDuty
  • ConfigとConfig Aggregator
  • CloudTrail
  • SSO
  • Securityhub

サービスの統合度合い

これがまた統一されていなくて、ややこしい。 基本的にそれぞれのサービスは、アカウント単位かつリージョン単位での管理がまずベースにある。 そして、サービスによって、マスターアカウントとメンバーアカウントの関係を構築して集中管理できるものや、Organizationsの組織に対して一元管理できるものなどがある。せっかくOrganizationsあるんだから、OU単位で扱えるように統一して欲しいです。

Security Hubでできること

  • Amazon GuardDuty、Amazon Inspector、Amazon Macie AWS Identity and Access Management (IAM) Access Analyzer、AWS Firewall Managerなどのアラートや検出結果を一元管理できる
  • マスターアカウントとメンバーアカウントによる集約
  • Security Hubを使うには、そのアカウントでAWS Configが有効になっている必要がある。

Organizationsで使えるサービス

  • CloudTrail
    • マスターアカウントで組織のすべてのアカウントのログを記録できる
  • Config
    • アグリゲーターを使うことで組織全体のConfigデータを統合して可視化できる
    • アグリゲーターにより、単一アカウントの複数リージョンのデータを集約することも出来る
    • マルチアカウントに対してルールを集中的にプロビジョニングすることはできない。Configデータの収集のみ。ルールは個別にプロビジョニングする。
    • ルールの適合結果をメールなどで通知をしたいときは、ConfigからSNSトピックに投稿することができる。ただし、全部のタイミングで通知が発生するので、OKかNGかの判定結果に変化があったときだけ通知するようなニーズであれば、CloudWatch Eventsを使い、そこからSNSトピックに投稿するほうが便利。

※GuardDutyもOrganizationsでの一元管理に対応されました。 Amazon GuardDuty が、AWS Organizations のサポートでマルチアカウントの脅威検出を簡素化

最後に

まだまだ書き足りないのですが、いったんここまで。

プレゼンテーションのコツ

エヴァンジェリスト養成講座をあらためて読み直す機会があったので、まとめておくことにした。

新エバンジェリスト養成講座

新エバンジェリスト養成講座

この本は、セミナーのセットで購入したのだが、セミナー自体が激オススメです。

プレゼンテーションとは

  • プレゼンのゴールは相手を動かすこと。話すことでも伝えることでもない。
  • 相手を動かすことをゴールにおくと、資料のレビュー観点も変わる。
  • 動かす例
    • 無関心を関心ありにする
    • 協力者になってもらい、自分の支援をしてくれるようになってもらう
  • プレゼンテーションでは仕様より体験、価値を伝える
  • 伝えたいことは何か?をブレークダウンして考える。要言語化。「新商品について伝えたい」はボンヤリしている。

視線誘導について

  • 言葉で視線誘導する。そうできるようにスライドを作っておく。
  • 視線誘導がとても大事。聞いていることと見ているものがズレていると入ってこない。

シナリオを作る

  • 3:7の時間配分。本題7割、その前に課題提起とその回答に3割時間を充てる
  • 相手にどういう行動を期待するかを決め、プレゼン中に語りかける、タイトルやサブタイトルに入れる
  • ポイント
    1. なぜこの話をしなければならないのか?
    2. なぜ私はここにいるのか?
    3. なぜみなさんはここにいるのか?

デマンドを植えつける

  • ほしい!やりたい!使いたい!と思う気持ちを植え付けること
  • ないとどうなるか?どう困るか?を訴えるホラーストーリーが良い

スライド作成のヒント

  • タイトルスライドは長く表示されるのでかっこよくする
  • 1枚の中に同じワードが繰り返されないよう重複排除する

話し方

  • 相手を見てしゃべることが難しい場合、それでは、続いて、そして、実は、なぜなら、といった接続詞のタイミングで相手を見るだけで、顔を見ているという印象になる
  • カウントするときや、順序を説明するときは指を使う
  • 最後のことばはあらかじめ準備しておくと良い
  • 話し始めのことばも考えておくとよい
  • 最初に、終了時間を告げること。相手が集中しやすい
  • スライドにはファクトを書き、プレゼンでオピニオンを添えて読む。「5%というわずかな確率なので気にしなくてもよいでしょう」
  • 絶対時間と相対時間を合わせてしゃべる。3年前の2017年の頃、、。相対時間は身近に感じて行動を促しやすい。
  • 体言止め、質問と回答、魅力の語尾、を使ってプレゼンを単調ではなく魅力的にする
  • 最初のうちに、うんうんとうなずいて聞いてくれる人を見つけ、ペースメーカーにする。

平成から令和になり、うどんからドライヤーにクラスチェンジした話

うどんとの出会い

AirPods Pro買ったのでレビュー

Apple AirPods Pro

Apple AirPods Pro

  • 発売日: 2019/10/30
  • メディア: エレクトロニクス

うどんうどんとAirPodsを半ば馬鹿にしていた私ですが、通勤中の英語の勉強や音楽を聴くのに買ってみて、ワイヤレスイヤホンのあまりの便利さにしてやられたと感じました。スマホと耳をつなぐケーブルが実はいかに邪魔で、ユーザー体験を損ねていたのかを思い知ったしだいです。

そんな私が、ノイズキャンセル機能付きのAirPods Proを購入し、ようやく手元に届きましたのでレビューしたいと思います。

令和になりうどんもバージョンアップ

届きました、AirPods Pro! 実は注文したのは昨年の12/16日のこと。最初は11/13日にAmazonでオーダーしたのですが、まてど暮らせど入荷予定のめどが立たず、痺れを切らして公式から注文し直し、Amazonはキャンセルしました。 ですので、欲しい!買うぞ!と決めてから2か月ほど待たされたわけです。

箱はこんな感じですね。 まあいつものアップル製品らしい佇まいです。 というわけでさっそく開封します。 毎回思うのですが、フィルム包装されていますが、はがし始めるところが用意されていて、こんな感じにとても開けやすい。 この気配りが、地味に嬉しいです。最近子どもにDVD(Blu-rayではなく、、)を買ったのですが、フィルムピッチピッチ包装で、開け口もなく爪でカリカリやってフィルムをワイルドにひき裂いて開封するハメになるのですが、実にストレスフルなユーザー体験ですよね。みなさん見習って欲しいのですが、特許でも取っているのか、他社プロダクトであまり見ないんですよね。コストの問題かなぁ。

箱を開けたところです。シンプル。 取り出したところ。 先代より横長のケースの中に、ドライヤーが入っています。慣れるまで、ケースから取り出すのが難しかった。指でつまもうとするのではなく人差し指の腹で押し出すようにしてやると取り出しやすいです。 本当にドライヤーみたいですね。

軸に少し平らになった部分があるのが見えますでしょうか。ここをつまむとカチッとクリックできるようになっていて、再生を開始したり、曲送りしたりと、操作をすることが出来ます。長押しするとノイズキャンセルの有無を切り替えられます。従来のAirPodsではトントンっとタップする操作系でしたが、Proではカチッと感があるので、より分かりやすいように思います。本当にクリックできているのか、ハプティックでそう感じるような仕組みなのかは分かりませんが、Goodですよ。

ファーストインプレッション

とりあえず使ってみました。たまたま洗濯機を回しながらだったのですが、耳に入れてしばらくすると少しトンネルに入ったときのような違和感があり、続けてシーンとがなりました。これには本当に驚き、一瞬何が起こったのわかりませんでした(大げさかもしれませんが、ノイズキャンセルイヤホンは初めてだったので本当に驚いた)。 試しにノイズキャンセルをOFFにしてみたところ、洗濯機はちゃんと回っていました。

これは通勤電車の中や、新幹線車内での使用に期待できそうです。来月は出張で新幹線に乗るので、忘れずに使いまくりたいと思います。

2020/01/14追記 通勤電車の中で使ってみました。高めの音はけっこう聞こえることが分かりました。例えば線路の継ぎ目のガタンという音。対して、ゴーという風切り音はほとんど聞こえなくなります。あえてそういう仕様になっているかも。もしくは、AirPods Proのノイキャンの仕組みは知りませんが、瞬間的に発生する音はキャンセルが難しいのかも知れませんね。

Gitこんなときどうする(GitLab)

社内でGitLabを使い始めました。個人レベルでPC間のファイル同期用途としては以前から使用していたのですが、実務かつ複数人で使い出すと操作に困ることが多かったので、『このときはこう!』というのを書き残していきたいと思います。

そもそものブランチの使い方

これには正解はないが、今のところGitLabFlowをベースにしてこんな感じのルールにしています。

リモートリポジトリにはmasterとstagingとproductionを用意。masterは最初からずっと、stagingとproductionは初回リリース以降はずっと存在し続ける。作業は、masterから要件単位にfeature/xxxブランチを切って行う。

ローカルの作業はfeatureブランチで行い、コミットは各自のタイミングで。単体テスト終わるまではそのまま。テスト完了したものをpushし、masterブランチにマージリクエストする。

ある程度の区切りで、masterブランチをstagingブランチにマージして、ステージング環境での動作確認や顧客デモを行う。

実際のリリースタイミングでproductionにマージしてバージョンタグ(v1.1.0など)を付けています。

このときはこう

ローカルリポジトリで細かくコミットしているが、細かすぎるのでまとめたい

ローカルリポジトリのコミットは個人の自由なタイミングで行っています。ですが、1つのfeatureの実装が終わり、ソースレビューに出すときなどに、細かなコミット多いとログインが汚れるし、レビューする側も見づらいです。

そんなときは、複数のコミットをrebase -i でまとめます。

$ git rebase -i

出力イメージ

pick 9dfab7ac 〇〇機能追加しました

pick c04aced8 レイアウト調整

pick ee35f7dc テストコード追加

エディターが開き、コミットが古いものから順にリスト表示されるので、pickをsに変更する。

 

ブランチ切って開発中に、リリース済みのバージョンに緊急対応が発生したとき

作業中ブランチでは緊急対応しないこと。masterからhotfixブランチを切って、対応してmasterにマージする。masterには、前回のリリース以降に開発した、未リリースのfeatureがマージされている可能性があるので、hotfixのマージコミットだけをcherry-pickして適用する。

 

作業中のブランチに、他の人のコミットを取り込みたいとき 

他の人のコミットをすべて取り込んで、最新のベースに合わせるときは、rebaseをする。

hotfixブランチで対応したものだけを、開発中のブランチに取り込むには、cherry-pickを行う

 

戻したい系

コミットを取り消す

コミットを取り消すには、reset(リセット)を使う

  • コミット操作を取り消す(変更内容を未コミットに戻す)

$ git reset --soft HEAD^

  • コミット内容ごと取り消す(変更内容も無くなる)

$ git reset --hard HEAD^

取り消したことを取り消す(直前のリセット操作を取り消す)

$ git reset --hard ORIG_HEAD

プッシュを取り消す

$ git revert 

$ git push

マージを取り消す
  • マージしようとしたらコンフリクトして編集もしたけど諦めてやっぱりやめたいとき

$ git reset --hard HEAD

  • マージ完了、未プッシュのとき

$ git reset --hard ORIG_HEAD

  • マージ完了、プッシュもして共有済みのとき

$ git revert -m 1 <マージコミットのID>

 GitKraken

Git操作にGUIツールとしてGitKrakenを使っているので、そちらについてもメモ。

リベース操作

GitKrakenでリベース操作をする際に、いつもいつも操作を間違えるのでメモを残しておきます。

dev, topicの2つのブランチがあって、topicブランチで開発中にdevがけっこう伸びてきたのでリベースしたい。topicはまだ開発中なので、マージするのではなく、最新のdevを取り込んでおきたい。

操作
  1. topic/XXXブランチをチェックアウトする
  2. devブランチ上で右クリックし、"Rebase topic/XXX onto dev" を実行する
  3. コンフリクトなどに適宜対応し、完了する

 まだまだカバーしきれていない「こんなときどうするっけ?」がありますので今後も更新していく予定。

プッシュする前にコミットをひとつにまとめたい

こちらもリベースを使います。

ローカル作業中に、ちょっと大きなリファクタリング着手する前とかで自由にコミットできるのがGitのいいところです。しかしながら、そのままプッシュすると、『リファクタリング前にいったんコミット』『テストコード修正』『修正コメントを追記』みたいに、ちょっと散らかったコミットログになってしまいます。

リベースを使うことで、プッシュする前に複数のコミットをひとつのコミットにまとめてからリモートに反映することができます。

操作
  1. まとめたいコミットたちの先頭のコミットのひとつ前のコミットを右クリックする
  2. interactive rebase ... を選択
  3. 対話リベース画面が開くので、上から全てsquashに変更する。一番下のみrewordにする
  4. 実行する