タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

gitに関するnunulkのブックマーク (10)

  • rebase 教から脱退します - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中に

    rebase 教から脱退します - Qiita
    nunulk
    nunulk 2024/04/21
    いやー、コミットログはきれいにしてほしいなぁ。ローカルではrebase、いったんプッシュしたらmerge、だけど大事なのはトピックブランチを長期間放置しないこと。rebaseもmergeもしないのがいちばんいいので
  • 2024年Gitワークフロー再考 | フューチャー技術ブログ

    春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で

    nunulk
    nunulk 2024/04/10
    squash は賛否両論あるねぇ
  • Feature Flag Deep Dive

    チーム勉強会で Feature Flag とトランクベース開発の話をしました (追加訂正と書かれているスライドは、勉強会後議論した結果を反映したものです)

    Feature Flag Deep Dive
  • Conventional Commits

    Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文: <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳: <型>[任意 スコープ]: <タイトル> [任意 文] [任意 フッター] あな

  • Gitのコミットメッセージの書き方(2023年ver.)

    記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変

    Gitのコミットメッセージの書き方(2023年ver.)
    nunulk
    nunulk 2023/01/05
    git 公式では現在形ではなく命令形を推奨してるようだけど、個人的には意味が通じればどっちでもいいな、日本語なら体言止めも使える(どっちにも取れる
  • 特別な理由なしにgit-flowを新規採用するべきではない - Qiita

    Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた(のチーム)が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき

    特別な理由なしにgit-flowを新規採用するべきではない - Qiita
  • Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々

    Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

    Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
    nunulk
    nunulk 2021/05/19
    知らんかった / "今は --force-with-lease があるのでこれを絶対に使う"
  • 入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita
    nunulk
    nunulk 2020/10/11
    --mixed はデフォルトの動作なので、明示的に指定する必要はない。--hard もたまに使うので覚えておくといいかも
  • 脱ブランチファースト - 日々常々

    あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト(造語) 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン( master ブランチ)に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙

    脱ブランチファースト - 日々常々
    nunulk
    nunulk 2019/10/27
    プロダクトに対するチームメンバーの認知の差をできるだけ小さくしたい、というのは日頃から感じているので、どこかで試してみたい
  • 10 Git Anti Patterns You Should be Aware of

    This is the slide deck I presented at ITAKE UnConf 2018. Git is one of the most powerful tool in developers' toolbox. If you use it correctly, it dra…

    10 Git Anti Patterns You Should be Aware of
    nunulk
    nunulk 2019/06/27
  • 1