一人十郷 - takuminasuno.com 一人十郷
takuminasuno.com
ビジネス
2025/01/27

Dataform上でSQLを書いてBigQueryにある小売業の売上データ分析をしてみた

こんにちは。那須野拓実です。

以前書いた「Dataformを使ってBigQueryにあるGA4データを加工してLooker Studioで可視化してみた話」という記事でDataformの基本的な使い方をまとめた際、その中で簡易的なSQLも紹介していました。ただ、実務を考えるとちょっと物足りないというのが正直なところでした。

Dataformをデータ分析の実務で使えるようにするには、データ分析のためのSQLの基本的な書き方を押さえていくことが必須になります。

今回は、小売業の売上データを分析することを想定し、サンプルデータに対して全ての処理をSQLで書いたうえで、データ処理の型としてまとめてみたいと思います。なお、元となる各データソースはGoogleスプレッドシートに置いており、Googleスプレッドシートを参照して外部テーブルを生成するところからスタートする前提で進めます。

データ処理の概要

元となるデータソースのサンプルは以下の5テーブルです。小売業の売上データになりますが、EC主体で、店頭でのビジネスも小規模ながら展開しているビジネスをイメージしています。

  1. ec_order - ECの注文履歴。
  2. ec_order_line - ECの注文明細。注文履歴に紐づいて、商品ごとにレコードが生成される。
  3. ec_product - ECの商品一覧。
  4. ec_customer - ECの顧客一覧。
  5. shop_order_line - 店頭の注文明細。システムの仕様のため、レシートの明細ごとのレコードのみ存在。会員カードを使用した顧客については、ECの方の顧客IDが紐づく。

データ処理の中では、ECと店頭にまたがるデータを統合し、顧客それぞれについて購入金額や購入頻度、購入商品カテゴリー、値引き感応度などを集計して、最終的にマーケティング観点での顧客セグメントを割り当てるところまでをやりたいと思います。

データ処理のデータリネージ

データリネージ(データの処理の流れ)は、テーブル単位で書くと以下のようなイメージです。

注文単位で生成されるorder、そしてorderの中の細かい商品明細の情報を持つorder_lineの2種類について、ECと店頭にまたがるデータを統合し、最終的に両データを集計のうえ顧客セグメントを定義する流れになります。

詳細はGitHubのリポジトリに譲りますが、SQLとしては特殊な構文はそこまで使っておらず、SELECT句、WHERE句、GROUP BY句、ORDER BY句、JOIN句、WITH句あたりが使えれば基本的には大丈夫です。ただし、以下2点については留意をしたうえで次の章に進みましょう。

  1. customerテーブルだけは顧客セグメントに集約する処理をSQLでやり切るのが大変なため、データ加工の一部をJavaScriptで定義している。
  2. 各データソースが理想的ではなくだいぶ汚いため、いくつかまどろっこしいデータの加工を行っている。(※最後のまとめで確認します)

教科書通りにはいかない、というのが現場のデータ処理ですね…。

SQLによるデータ処理の型

それでは、GitHubのリポジトリにあるコードを参考に、Dataformによるデータ処理あるあるの型を見ていきたいと思いますこれが全てではないですが、これらを押さえれば最低限の基本にはなるのかなと思います。

なお、元データとなるスプレッドシートもセットで公開しているので、併せてご利用ください。それでは見ていきましょう。

①テーブルの新規作成(config.type:'table')

Dataformはconfig.typeによって基本的なデータ処理を簡易に実装できるようになっており、そのうちの1つがテーブルの新規作成になります。config.type:'table'にて宣言すると、SELECT文を書くだけで自動的にテーブルを作ってくれるというものです。

コツは、カラム名を定義する場合はconfig.columnsに設定すること、そして他のテーブルを参照するときは ${ref('ec_product')} のように他のSQLXファイルで定義したテーブルのnameをrefによる参照記法の中に入れることですね。

例えばproductのテーブル作成は、以下のようなSQLで実装しています。ちなみにちょっとしたデータ加工として頻出するのが、以下のようなWHERE句やORDER BY句です。

  • WHERE句によって、商品IDがあるレコードに絞っている。
    ※一般的な等価演算子や比較演算子だけでなく、NOTやINなどの演算子や、LIKEや REGEXP_CONTAINS演算子による曖昧一致などを使っていくことになるので、演算子についてはしっかり押さえておきましょう。
  • ORDER BY句によって、商品IDで昇順にレコードを並び替えている。
    ※昇順(ASC)か降順(DESC)かは省略でき、省略すると自動的に昇順(ASC)となりますが、ぱっと見では分かりづらいので個人的には明示的に書く方がよいと考えています。


なお、このconfig.type:'table'は、カラムのデータ型が自動定義される点には注意が必要です。カラムのデータ型を間接的に定義したい場合は、SELECT文の中で意図的にキャスト(型変換)するか、もしくは後述するconfig.type:'operations'で対応する方がよいでしょう。

②グループ化(GROUP BY句)

BigQueryの集計と言えば、まずはGROUP BY句でしょう。トランザクション系のデータを、様々な単位で集約・集計することができます。グループ化するキーとなるカラムはGROUP BYの後に記述しつつ、それ以外のカラムは集約関数(MIN, MAX, SUM, COUNTなど)に入れておきます。

今回例に挙げている購買データであれば、顧客単位に集約する集計が頻出します。例えばcustomer_order_totalのテーブルです。

GROUP BY句を実際に書くときは、他の句とセットで使うことが多いですが、WHERE句の後、ORDER BY句の前に書くと覚えておきましょう。


※参照することの少ない中間テーブルなので、カラムのdescriptionは省略しています。これぐらいの行数だとシンプルで見やすいですね。

③トランザクションへのマスタ結合(LEFT JOIN句)

GROUP BY句と同じくらい多いデータ処理の1つが、LEFT JOIN句によるマスタ結合だと思います。そもそもJOIN句は、LEFT JOIN以外にもいくつか種類はありますが、ここではLEFT JOINだけを紹介します。気になる方は調べてみてください。

データベースでは「誰が、いつ、どこで、何を、どうした」という履歴であるトランザクションデータを保持しますが、多くの場合、この「誰が」「どこで」「何を」といったデータはIDだけを持ち、そのIDに紐づく静的な詳細データを別のマスタテーブルに保持します。

例えば購買データであれば、商品IDに紐づく形で商品情報を整理し、それを商品一覧のテーブルとして独立して管理しがちです。結果、購買履歴のテーブルには「何を買ったか」を表す商品IDはあるものの、その商品名や商品カテゴリ、定価や原価などは商品一覧のテーブルを参照する必要が出てきます。

データ分析の際にはそういった情報を付与したうえでデータを見ることが必要不可欠なので、LEFT JOIN句は非常に重要になっています。

具体例として、shop_order_line_with_discountのSQLを見てみます。先ほどと同じようにconfig.type:'table'でテーブル作成していますが、SELECT文の中にLEFT JOINが入っていますね。


ポイントとして、LEFT JOINをする際はSQLの中に複数のテーブルが登場するため、どのテーブルのカラムか区別するために、カラムを{table_name}.{column_name}で明示的に定義するようにしておきましょう。

なお、{table_name}は文字数が長い場合が多いため、SQL上では省略することが多いです。テーブル名の頭文字を使ったり、a,b,cのようなアルファベットの始めの文字を使ったりすることが多いです。

④複数トランザクションの統合(UNION ALL句)

LEFT JOIN句に次いで頻出するのが、UNION ALLによるトランザクションの統合です。複数のテーブルに分かれている同型のトランザクションを、カラム構成を整えつつ統合します。

具体例として、orderテーブルのSQL(※後述する差分同期処理の一部なので留意のこと)を抜粋します。この例では、店頭の売上データとECの売上データを統合して1つのテーブルにしています。

カラム構成が一致していることが必須であるため、差分がある場合は以下のように各カラムを整えてあげる必要があります。


押さえておきたいポイントは、ソートするタイミングでしょう。UNION ALLで足した後に、最後に全体に対してソートを効かせるような置き方なので注意しておきましょう。

⑤差分処理の実装(MERGE句)

トランザクション系のデータは日々増えていくため、全数のデータを定期的にクレンジング対象や集計対象にしていたらBigQueryのスキャン量、つまり請求額が加速度的に増えていきます。そのため、一定以上の量(初期のボリュームないし肥大化速度の観点で)があるテーブルについては、更新されたデータだけを処理する差分処理の実装が重要になってきます。

Dataformでも差分処理はサポートされており、config.type:'incremental'によって簡単に実装可能なのですが、大きな落とし穴があります。というのも、これはいわゆるupsertのみ(updateとinsert)が対象となっており、元データがdeleteされたときは処理の対象外となっているのです。

もちろん実行時オプションで [完全に更新して実行する] にチェックを入れることで全データを再計算して元テーブルのdeleteされたレコードもケアすることは可能ですが、元データのdeleteが定期的に起こる運用においてはあまり望ましい処理ではありません。

deleteも含めてリアルタイムな同期をということであれば、累積テーブル、差分テーブルをSQLで作り、MERGE句によってINSERT, UPDATE, DELETEそれぞれの場合を律儀に実装する必要があります。幸い、Dataformではconfig.type:'operations'によって自由にSQLを書けるので、以下のような実装が可能になっています。


ただし、見ての通り、かなり長くなってしまいます。なんと111行です…。

そのため、operationsで律儀に書くか、incrementalによる実装ができるかどうかは、運用としてどこまで許容できるかの観点で慎重に検討しておいたほうがよさそうです。もしincrementalで実装できる場合、今回の例で言えば111行だったコードが以下のように69行に激減するのは無視できない魅力です。

⑥グローバル変数の使い回し(projectConfig.vars)

複雑なワークフローを組む際は、同じコードを使い回したいことが出てくると思います。また、特定の部分だけ書き換えて実行したいという場合も出てくると思います。そういった場合に有効なのが、projectConfig.varsによって定義されるコンパイル変数になります。

前項のorderテーブルを作るSQLにて登場していた


という表現が1例です。コンパイル変数の特徴として、

  1. デフォルト値を [workflow_settings.yaml] ファイルにて定義できる。
  2. リリース構成へのコンパイル時に、リリース構成ごとに個別に上書きできる。

という2点があり、うまく組み合わせることで融通の利く開発と実行が可能になります。

1つ目のデフォルト値については、例えば今回のプロジェクトであればworkflow_settings.yamlにて以下のようにデフォルトの集計期間をBETWEEN句で定義しています。


上記はサンプルなので日付をハードコーディングしていますが、実際の運用ではDATE_SUB関数やDATE_TRUNC関数を使うといろいろなパターンが実装できて便利ですね。(※データの性質によって微妙に変更が必要な場合はあるのでご留意ください。)

  • 直近7日間 - BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
  • 今月 - BETWEEN DATE_TRUNC(CURRENT_DATE(), MONTH) AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
  • 先月~今月 - DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH), MONTH) AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)

そして2つ目のコンパイル時の上書きについてです。 コンパイルするときに以下のように [コンパイル変数] を入力することができるようになっています。

なので、

  • キー1:EQUALS_CALC_DATETIME
  • 値1:BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)

のように入力してリリース構成に「直近1週間の集計」のように名前を付けて保存をすることで、全集計ではなく直近1週間だけのデータを更新するリリース構成にすることができます。

この組み合わせによって、

  • エディタ上のテスト実行 - 完全な更新
  • リリース構成「直近1週間」- 直近1週間分の差分更新
  • リリース構成「今月」- 今月分の差分更新
  • リリース構成「先月~今月」- 先月~今月分の差分更新
  • リリース構成「全体」- 完全な更新

のように任意の期間での再集計が可能になります。実務上は集計条件を微妙に変えて実行したいケースが多いですが、そのときに原本のコードを都度変更するのはリスクがあります。運用にて変えうる部分はコンパイル変数にしてリリース構成で上書きできる設計にしておくとよいでしょう。

⑦JavaScriptによる複雑な集計(CREATE TEMP FUNCTION)

Dataformの特長として、CREATE TEMP FUNCTIONメソッドによってJavaScriptを使ってデータ処理を実装して複雑な集計を実現できる点があります。

CREATE TEMP FUNCTION自体がSQLのため、config.type:'operations'による実装にはなりますが、トランザクションをもとに集約する場合や、FORループを使いたい場合、多段階の変数処理が入る場合などはJavaScriptによる実装の方が有利です。

今回のデータパイプラインではcustmerテーブルにて各種顧客セグメントを作る際に利用しており、実際のコードが以下になります。

全体感としては、CREATE TEMP FUNCTIONで複数の関数を定義したうえで、最後にCREATE OR REPLACE TABLEメソッド1本で集計しています。(※押さえておきたいコツが多いので、それはコードの後で説明します。)


 

まず、JavaScript関数の定義の仕方を確認しましょう。もっともシンプルなget_age関数を見ると、引数であるdate_of_birthとyesterdayを型とセットで定義のうえ、戻り値をSTRINGにしてjs(JavaScript)で書いています。独特な感じはありますが、慣れればあとはJavaScriptを書くだけなので分かりやすいです。


実際に関数を使う場合も、以下のようによくある関数的な書き方で通ります。(コンパイル変数については前項を確認ください。)


 

ちなみに、引数に配列を設定することももちろん可能です。ただし、配列を定義する書き方に癖があるので、丁寧めに確認していきましょう。まず関数の定義では、以下のように

ARRAY<STRUCT<{カラムをカンマ区切りでデータ型とともに並べる}>>

のように記述することで、いわゆるトランザクションの配列を引数にすることができます。以下の例では、product_summaryを配列として引数に設定しています。JavaScriptの中は通常のJavaScriptの書き方で大丈夫なので安心ですね。


配列を引数にする場合は、実際に関数を使う場合の引数の作り方も特殊です。

今から確認する例では、customerテーブルを作る前にcustomer_order_line_detailというテーブルとして事前に作っているのですが、その中でARRAY_AGG関数とSTRUCT関数によってトランザクションデータを配列として1つのカラムproduct_summaryに集約しています。集約なので、GROUP BYを忘れずに書きます。


ここまでできれば、実際に関数を使うときはシンプルです。


この処理の基本を頭に入れてもらってから改めてcustomerテーブルのSQL全体を見ると、JavaScriptによるデータ加工の流れが見えてくると思います。

ひと工夫が必要ではありますが、トランザクションをもとに集約する場合や、FORループを使いたい場合、多段階の変数処理が入る場合などはJavaScriptによる実装の方が有利です。応用編として、ぜひ覚えておきましょう。

⑧スプレッドシートの外部テーブル化

元のデータソースに立ち戻ります。今回はスプレッドシートをデータソースにしていますが、スプレッドシートを集計対象とするにはBigQueryの外部テーブルとして作っておく必要があります。もちろんBigQuery上の手作業で外部テーブルを作成することもできますが、再現性の観点ではDataform上で実装できていたほうがよいでしょう。

処理としては、CREATE OR REPLACE EXTERNAL TABLEのメソッドを使います。コツとしては、

  • OPTIONSにて対象シートを定義する。
  • config.type=operationsのため、Dataformのデータリネージ(COMPILED GRAPH)に登場させるためにconfig.hasOutput:trueに設定しておく。

を押さえておきたいところです。以下にec_customerテーブルのSQLを転載します。

⑨パーティショニング

BigQueryはデータ処理のエンジンが非常に強力なため、どんなにテーブルが大きくても数秒~数十秒くらいでSQLを実行しきってしまいます。しかし、従量課金のBigQueryはSELECTのためにスキャンした行と列のデータサイズに応じた課金が発生するため、むやみやたらと大きなテーブルを作って集計すると数十万~数百万円の課金が発生して「BigQueryで〇〇万円溶かした人」みたいな悲劇が発生しがちです。

大きくなりがちなテーブルの筆頭は時系列データをどんどん蓄積していくトランザクション系テーブルですが、スキャン量を減らすためにテーブルを分けるというのは本末転倒です。この問題に対してGoogleが提供している仕組みが、パーティション分割テーブルないしパーティショニングという仕組みです。

テーブルを日付カラムをもとに疑似的に分割し、SELECTの際にWHERE句でその日付カラムによって絞ることで、スキャン対象の行を絞ることができます。この仕組みを使うと、例えば直近7日間のデータのみを毎日再集計するような仕組みが可能のため、スキャンするデータサイズを桁違いに減らすことができます。

今まで登場したすべてのトランザクション系テーブルでしれっと設定していますが、実はその定義の方法が2パターンに分かれています。というのも、config.type:'table'の場合と、config.type:'operations'の場合で書き方が違うんです。

config.type:'table'の場合

config設定にて定義できます。具体的には、config.bigquery.partitionByにて設定が可能です。以下の例は、shop_order_line_with_discountの抜粋です。

config.type:'operations'の場合

テーブル作成の際に、カラム定義を書いた後にPARTITION BY句を入れることで設定できます。以下の例はec_order_line_with_dateの抜粋です。

⑩その他細かいconfig設定

Dataformでのデータパイプライン作成では、SQLを書くことと同じくらい、冒頭のconfigを適切に書くことが重要です。というのも、Dataformで作成させたSQLXファイルはこのconfigの情報のみを持って管理されるからです。

必須項目であるconfig.typeを除き、共通して設定しておくべき5つのパラメータ(schema, name, description, hasOutput, tags)について確認しましょう。

config.schema

このSQLXファイルで参照されるテーブルがBigQuery上でどのデータセットに該当するかを定義するものです。デフォルトのデータセットは [workflow_settings.yaml] にて定義されますが、複数のデータセットにまたがる場合は明示する必要があります。結論、全てのSQLXファイルで明示的に書くことが推奨です。

というのも、config.schemaが制御する範囲が限定的となっているからです。具体的には、

  • ref関数やCOMPILED GRAPH(データリネージ)がテーブルを探す際は、config.schemaのみを参照する挙動を取る。
    →config.type:'operations'のSQL内でデータセットを明示していたとしても、config.schemaを定義していなければ、勝手にデフォルトデータセットを参照されてエラーに繋がりやすい。
  • 逆に、config.type:'operations'では、config.schemaで定義したデータセットによってSQLのデータセットを上書きしてくれない。
    →config.type:'operations'では、SQL内でデータセットを明示する必要がある。

という2点があります。細かいことを考えずに全てのSQLXファイルで明示的に書くことが、ルールとしても分かりやすいですし、configだけを見ておおよそファイルの理解ができて読み手にも優しいので推奨です。

config.name

SQLXのファイル名です。デフォルトはファイル名の拡張子を除いた部分になりますが、config.schemaと同じく全てのファイルで明示的に設定すること推奨です。というのも、configにデータセット名だけ書かれていてテーブル名がないのは、直感的に読みにくいからです。

レアケースに対する注意点として、config.type:'operations'のSQLXファイルで中間テーブルを含めて複数のテーブルを作成する場合、ref関数で他ファイルから参照したいテーブル名でconfig.nameを書いておく必要があります。

今回の例でも、⑤差分処理の実装(MERGE句)で紹介しているようなトランザクションテーブルでは累積テーブルと差分テーブルがありますが、config.nameで指定しているのはもちろん累積テーブルの方になります。

config.description

SQLXファイルの説明です。ここに説明を書けば、BigQuery上でテーブルの説明に反映されるので便利です。ぜひ設定しましょう。

なお、例に漏れずconfig.type:'operations'の場合はconfig.descriptionに書いてもBigQueryテーブルには反映されません。BigQueryテーブルの説明に無理やり反映するには、テーブル作成時のOPTIONSにdescriptionパラメータを設定する必要があります。

重複入力にはなりますが、読み手への優しさを考えれば共通して記述しておくべきでしょう。

config.hasOutput

ref関数の参照先にできるようにするか、COMPILED GRAPH(データリネージ)に登場させるかのパラメータです。通常はデフォルトでtrueですが、config.type:'operations'の場合のみデフォルトがfalseのため、注意が必要です。

他テーブルから参照しうる場合は、忘れずconfig.hasOut:true に設定しておきましょう。

config.tags

実行時にまとめて実行する単位をタグとして設定可能です。実行タイミングの異なるSQLXファイルに名前を付けてタグとして設定しておきましょう。

まとめ

長くなりましたが、Dataformのデータ処理の基本の型として①~⑩の10点をまとめました。これらを押さえておけば、とっかかりとしては十分ではないかな…と思います。

なお、今回のデータソースのサンプルはある意味現実的でだいぶ汚いため、いくつかまどろっこしいデータの加工が必要になっています。SQLを細かく読んだ人が「なぜこんなことを…?」と思いがちなポイントを4つほど挙げておきます。

  1. BigQueryで費用を抑えるには日付データ等でのパーティショニングは不可欠。だが正規化されているEC注文明細の元データには日付情報がないため、補完のために大元のEC注文一覧テーブルをジョインしている。
  2. 店頭の方の注文明細には、最終的な販売価格しか記録されていないため、定価や値引き額が分からない。そのため、商品一覧をジョインして定価を紐づけ、値引き額を再現している。
  3. 店頭の注文データは明細単位しかないため、明細情報をレシートID単位でユニーク化して注文テーブルとしている。なお、値引き情報の完全再現は不可能なため、値引きは明細単位にそのまま割り振り、注文単位の値引きは0円としている。
  4. リネージを綺麗にするため、EC側の注文明細にも商品一覧テーブルをジョイン。ECと店頭のデータを結合して注文明細テーブルにしたときに、商品名や商品カテゴリなどが1テーブルに揃っている状態とした。

データ処理の実務は思わぬところで躓きがちで、大変ですね。

この記事がいつかどこかの誰かの型の助けになれば幸いです。

おまけ:DataformとGitHubとの連携方法

最後に、本記事でも利用しているGitHubプロジェクトのコード同期についても書いておきます。

Dataformは環境の区別や本番環境へのコミットの概念はあるものの、バージョン管理ツールとしてできることは限定的です。一方で、GitHubとの連携機能を持っており、連携することでGitHubにて本格的なコードのバージョン管理が可能になるため、チームでワークフローを管理したい方にとってはオススメになります。

Dataform公式ドキュメントを参考に、以下の手順で進めました。

①GitHubの設定

  1. GitHubにアクセスします。
  2. Dataformのコードを同期するリポジトリがない場合は、新たに作成しておきます。
  3. プロフィールの [Settings] > [Developer's Settings] > [Fine-grained personal access tokens] のタブを開きます。
  4. [Generate new token] ボタンを押し、[Token name] と [Expiration] の日数を適宜設定します。続いて、[Repository access] を [Only selected repositories]に変更して対象となるリポジトリを選び、[Permissions] にて以下のように設定し、最後に一番下の [Generate token] ボタンを押します。
    • [Contents] = [Read and write]
    • [Metadata] = [Read-only]
  5. tokenが生成されるので、値をコピーします。

②Secret Managerの設定

  1. Google Cloudを開きます。
  2. セキュリティサービスの中にあるSecret Managerにアクセスします。もし初めて使う場合は、Secret Manager APIを有効化します。
  3. [シークレットを作成] ボタンを押し、[名前] を適宜入力のうえ、[シークレットの値] に①でコピーしたtokenの値を貼り付けます。最後に一番下の [シークレットを作成] ボタンを押して完了です。

③IAM設定

  1. Dataformで初めてSecret Managerを利用する場合、IAMにて権限付与を行う必要があります。IAMにアクセスし、Dataformのデフォルトサービスアカウントに [Secret Manager のシークレットアクセサー] のロールを付与します。なお、プリンシパルの一覧には [Google 提供のロール付与を含める] にチェックしたら表示される点には留意しましょう。

④Dataformの設定

  1. Dataformを開き、GitHubにコード同期したいリポジトリを開き、画面上にある [Settings] メニューを開きます。
  2. 画面上に [Gitと接続] ボタンがあるので押します。
  3. [リモート リポジトリへのリンク] メニューが立ち上がるので、[リモートのGitリポジトリのプロトコル] を [HTTPS] に設定し、[リモートのGitリポジトリのURL] と [デフォルトのブランチ名] を適宜設定したうえで、[シークレット] のプルダウンにて②で作ったシークレットを選択し、[リンク] ボタンを押すと設定完了です。
    ※URLの設定時に「通常、リモートの git の URL の末尾は .git です。」のようなアラートが上がりますが、GitHubを利用する場合は自然と [https://github.com/{user_name}/{repository_name}] のようなURLになるので気にしなくてよいです。

⑤DataformからGitにPUSHする

  1. Dataformの開発ワークスペースを開きます。
  2. 中央左の3点メニューを押すと、[リモートブランチにpush] ボタンが表示されるので、クリックします。なお、下記の画面のように、デフォルトブランチにCOMMITしていないコードがあるとグレーアウトして押せないので、しっかりCOMMITしておきましょう。

⑥そしてGit作業へ

  1. これでリモートリポジトリにPUSHできるので、さっそくPUSHしたらGitHubを確認してみます。Dataformの開発ワークスペース名がそのままブランチ名になってPUSHされているのが確認できます。
  2. これで、あとは普段のGitのように利用しましょう。

同じカテゴリーの投稿もどうぞ!
ConoHa VPSにインストールしていたMetabaseに急にアクセスできなくなった問題を解決した話【503 Service Unavailable】
ビジネス
2024/11/14
ConoHa VPSにインストールしていたMetabaseに急にアクセスできなくなった問題を解決した話【503 Service Unavailable】
ConoHa VPSで作ったWordPressサイトを完全削除した手順メモ
ビジネス
2024/11/10
ConoHa VPSで作ったWordPressサイトを完全削除した手順メモ
Dataformを使ってBigQueryにあるGA4データを加工してLooker Studioで可視化してみた話
ビジネス
2024/10/20
Dataformを使ってBigQueryにあるGA4データを加工してLooker Studioで可視化してみた話
ConoHa VPSのWordPressサイトを複製してステージング環境を作った手順をまとめてみた
ビジネス
2024/10/05
ConoHa VPSのWordPressサイトを複製してステージング環境を作った手順をまとめてみた
ConoHa VPSにMetabaseをインストールして独自ドメインを宛がってみた話
ビジネス
2024/10/02
ConoHa VPSにMetabaseをインストールして独自ドメインを宛がってみた話
ブログ著者について
那須野 拓実(なすの たくみ)。たなぐら応援大使(福島県棚倉町)。トリプレッソを勝手に応援していた人。元語学屋。時々写真垢とか手芸垢。山とか滝とか紅葉とかが好き。本業はナレッジマネジメントとかデータ分析とかの何でも屋。コロナワクチン接種済み。