squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
Goのリリースプロセスとブランチ戦略 - YAMAGUCHI::weblog
はじめに こんにちは！Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか？ このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。 2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。 さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなっ
CIOpsとGitOpsの話 - inductor's blog
はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ？」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
モノレポのはなし / karino2 - Message Passing
モノレポについて経験豊富そうな皆さんの話を聞きたい。 まずはその背景から。 会社で分かれるレポジトリ フリーランスをやっていると、たまにいろんな零細企業を集めて一つのサービスを作る場に遭遇する。 人を集める時に、一つの会社だけじゃなくて複数の会社が集まることがよくある。 たとえばマーケティングが強みの会社が自社ではエンジニアを持っていなくて、開発は外部の人たちを集めてやるみたいな。 しかもそれぞれの会社からは一人とか二人だけしか来ないので、 6人の小規模なチームなのに会社は4つあるとかいう状況になったりもする。 そうすると何が起こるかというと、レポジトリが会社ごとに分かれたりする。 「クラウドとフロントの間はAPIを決めましょう、 それでクラウド側がバイナリをリリースして、フロント側がたまにそれをマージしましょう」みたいなフローになる。フロントとバックエンドなんて関わっているのは3人しか居
Co-authored-by署名を手軽に付与するためのGit alias - Steel Dragon 14106
Co-authored-by署名を手軽に付与するためのGit alias By raimon, 2019-12-08(日), in category Git GitHubでコミット時に複数の作者情報を署名する"Co-authored-by"という機能がある。 リンクしたGitHub Helpで解説されている通り、GitHub Desktop UIからは、入力補助で比較的簡単に共同作者によるコミットメッセージが作成できる。 開発者としてはGUIでなくコマンドライン上でコミットメッセージ作成する際も、手軽に入力したいところではある。インターネット上でやり方を探してみても、なかなか「これ」といった情報が見付からず、何かの役に立つかも知れないため自分の中でそこそこ上手く行っている知見を書いてみたい。 なるべく外部CLIツールに依存したくないため、全てGitの標準機能（Git aliasなど）で実現
XcodeGenによる新時代のiOSプロジェクト管理 - クックパッド開発者ブログ
こんにちは。モバイル基盤部の@giginetです。平成最後のエントリを担当させていただきます。 iOSアプリの開発では、Xcodeが生成するプロジェクトファイルである、*.xcodeprojをリポジトリで共有するのが一般的です。 しかし、この運用は大規模なプロジェクトになるほど、数多くの課題が発生します。 クックパッドiOSアプリは巨大なプロジェクトであり、通常の*.xcodeprojによる管理には限界が生じていました。 そこで、昨年秋にXcodeGenというユーティリティを導入し、プロジェクト管理を改善したので、その知見をお伝えします。 従来のプロジェクト管理の問題点 ファイル追加の度にコンフリクトが発生する *.xcodeprojファイルはプロジェクトに含まれるソースファイルの管理を行っています。 開発者がプロジェクトにファイルを追加すると、このプロジェクトファイルが更新されることにな
The largest Git repo on the planet
It’s been 3 months since I first wrote about our efforts to scale Git to extremely large projects and teams with an effort we called “Git Virtual File System”. As a reminder, GVFS, together with a set of enhancements to Git, enables Git to scale to VERY large repos by virtualizing both the .git folder and the working directory. Rather than download the entire repo and checkout all the files, it
「技術的革新について話すだけのヤツはクソだ、黙って手を動かせ」とLinux生みの親のリーナス・トーバルズが語る
Linuxカーネルを開発したリーナス・トーバルズ氏が、Linux Foundationが開催したOpen Source Leadership Summit 2017(OSLS 2017)で行われた対談で、近年のテクノロジー業界についてや、自身の仕事の考え方を語りました。 Talk of tech innovation is bullsh*t. Shut up and get the work done – says Linus Torvalds • The Register http://www.theregister.co.uk/2017/02/15/think_different_shut_up_and_work_harder_says_linus_torvalds/ OSLS 2017でリーナス・トーバルズ氏は、Linux Foundationで取締役を務めるジム・ゼムリン氏と対談を
次期Windows 10、一般ユーザーでもシンボリックリンクを利用可能へ -「mklink.exe」を開放
次期Windows 10、一般ユーザーでもシンボリックリンクを利用可能へ -「mklink.exe」を開放 Microsoftは12月2日(米国時間)、次期Windows 10でシンボリックリンクが一般ユーザーでも利用可能になると、公式ブログで発表した。Windows Vistaから本格的にサポートしたシンボリックリンクは、これまで管理者権限が必要だったが、同社は「開発者のユーザー経験を向上」を目的に本機能を開放すると説明している。 Windows Insider Program参加者にリリースしているWindows 10 Insider Preview 14972で開発者モードを有効にすると利用でき(ただし、PC版の最終公開OSビルドは14971)、Current Branchを選択している利用者は、2017年早期リリース予定のWindows 10 Creators Updateで本機能
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
[core-workflow] We will be moving to GitHub
Brett Cannon brett at python.org Fri Jan 1 14:21:05 EST 2016 Previous message (by thread): [core-workflow] Longer term idea: consider Rust's homu for CPython merge gating Next message (by thread): [core-workflow] We will be moving to GitHub Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] I don't think this will be a shock to anyone who has followed the discussion on this list. The d
SVNを捨ててGitを使うべき5つの理由 - Qiita
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです（たぶん）。 それが今で
デザイナーがXcodeを使って 開発効率をUPさせた 5つのエピソード + 現場エンジニアのコメント付き
非エンジニアリング脳なデザイナーが新規アプリ開発の現場でXcodeを使用することがどのような影響を与えたか。について、自身の経験を元にまとめました。
【前編】CTO不在で、開発組織改善に着手！ 一休のエンジニアが語る苦悩の1年
Twitterでハッシュタグ「#naoya_sushi」が生まれてしまうほど、無類の寿司好きとして知られる伊藤直也氏（@naoya_ito）。そんな伊藤氏をホスト役とし、トップエンジニアをゲストに招いて、寿司をつまみつつホンネで語ってもらおうという、この企画。 第四回のゲストは、伊藤氏が現在、技術顧問として就任し、開発部門の組織改善を行っている『株式会社一休』のエンジニア、宿泊事業本部のシステム開発部の部長である笹島祐介氏（写真中央）と開発組織改善の発起人である田中健介氏（写真右）の2名が登場！CTOが不在の開発現場で10年以上前からサービス提供している、そんなよくある状況の中、どのように現状の改革に挑んでいるのか――苦労話も炸裂し、現役エンジニアには興味深い話が展開されることに！お楽しみに！ — 伊藤直也（以下「naoya」）：とりあえず乾杯しましょうか。 — 笹島祐介（以下「笹島」）＆
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代開発を加速させる古来の術式
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
git の develop ブランチは必要なのか、またはリリースtagについて
Cookpad iOS Release Flow
