2025年1月19日に事実上のTikTok禁止法とも呼べる「外国の敵が管理するアプリケーションからアメリカ国民を守るための法案」が施行され、その影響でTikTokはサービスの継続が不透明な状況が続いています。そんなTikTokに対し、AIチャットボットなどを開発するPerplexityがTikTokの買収に関心を示しました。
TikTok買収にAI検索のPerplexityが名乗りを上げる、TikTokのアルゴリズムをオープンソース化するとアピール - GIGAZINE
- 買収を受け入れる
- アメリカから撤退する
のどちらが良いのかは分からないのですが、買収が成立した場合に「TikTok」の「アルゴリズム」が「オープンソース」になるかも、というのは気になりますな。
Gitのブランチ戦略の種類を整理してみるが...
何となく、
- main
- feture/*
- fix/*
- staging
- production
のような感じでブランチを分けるものだと思っていたのと、
⇧ stackoverflowなんかでも、似たような感じだったので気にしてこなかったのだが、
⇧「AWS（Amazon Web Services）」のドキュメントだと、デプロイは全て「main」ブランチからとなっている。
そもそも、どんな「ブランチ戦略」があるのかが謎なのだが、
⇧ 上記サイト様によりますと、
- Main-Only Strategy
- Feature Branching
- Gitflow
- GitHub Flow
- Trunk-Based Development
- Release Branching
の6つが紹介されていたのだが、このあたりがメジャーどころということなのだろうか？
■Main-Only Strategy
■Feature Branching
■Gitflow
■GitHub Flow
■Trunk-Based Development
■Release Branching
何やら、
- main
- staging
- production
でブランチを分けるのは、流行っていないのかね？
何で「ブランチ戦略」を調べてたかというと、
⇧「Ansible」のディレクトリ構成の「ベストプラクティス」で、「インベントリ」を、
- staging
- production
で分けているのよね...
つまり、「Gitリポジトリ」としては、「main」ブランチで、
- staging
- production
の両方の情報を持たせている形になりますと。
まぁ、「.env」ファイルとかで、
- development
- staging
- production
を分けることがあると思うのだけど、「.gitignore」の対象にして「Gitリポジトリ」では管理しないで、「Ansible」の複数の環境の情報を「Gitリポジトリ」の1つのブランチに持たせるに違和感を感じることもあるかもしれないが、正直、「ブランチ戦略」どうすれば良いのかサッパリ分からん...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
