並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 17 件 / 17件

新着順 人気順

git-rebaseの検索結果1 - 17 件 / 17件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

git-rebaseに関するエントリは17件あります。 gitGittechfeed などが関連タグです。 人気エントリには 『コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記』などがあります。
  • コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記

    Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu

      コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
    • 「Git 2.26」リリース、git rebaseのデフォルトバックエンドが変更される | OSDN Magazine

      分散型バージョン管理システムGit開発チームは3月22日、最新版となる「Git 2.26.0」のリリースを発表した。rebaseメカニズムの変更など、多数の機能が強化されている。 Git 2.26は1月に公開されたGit 2.25に続く最新版。大きな変更点としては、rebaseメカニズムの再実装がある。git rebaseのデフォルトでは従来は「apply」バックエンドがデフォルトとなっていたが、本バージョンではデフォルトで「merge」バックエンドが使われるようになった。これらのバックエンドは挙動が異なるため、もしワークフローが影響を受けた場合は、「rebase.backend」設定変数を「apply」に変更して以前のデフォルトに戻すことを推奨している。 リポジトリ間でのデータのやりとりを行う「Transport Protocol」では、「Transport Protocol v2」がデ

        「Git 2.26」リリース、git rebaseのデフォルトバックエンドが変更される | OSDN Magazine
      • Git履歴をgit resetとgit rebaseで管理する(翻訳)|TechRacho by BPS株式会社

        概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: How I manage my git history | Binary Solo 原文公開日: 2023/05/26 原著者: Ayush 日本語タイトルは内容に即したものにしました。 Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 私は全般的に、どちらかといえば規則にうるさい方ですが、自分のプロジェクトでgit履歴を管理するときはこの性格が役に立ちます。以前の私はGitHubの"squash & merge"方式をしばらく使っていましたが、その後Chris Mooreからいくつかのコツを教わりました。 私は"squash & merge"方式が好きになれません。どんなに巨大なプルリクエ

          Git履歴をgit resetとgit rebaseで管理する(翻訳)|TechRacho by BPS株式会社
        • git commit --fixup と git rebase --autosquash で簡単に commit が整理できて感動した話

          git commit --fixup と git rebase --autosquash で簡単に commit が整理できて感動した話 Written by @ryysud Apr 2, 2019 00:07 · 2636 words · 6 minutes read #git よくある面倒なシチュエーション PR を作成した際に、開発中にメインとなる実装の commit とは別に、レビューを受けての修正であったり、ちょっとしたリファクタリングであったり、typo 修正などの細かな commit を、PR の中で粛々と対応するシチュエーションは、どなたにも経験があることだと思います。そして、マージ前に git rebase -i を使って commit を整理するにしても、エディタを開き、どれがどれに紐付く commit なのかをマッピングするのは非常に面倒な作業だと思います。 そこで今

            git commit --fixup と git rebase --autosquash で簡単に commit が整理できて感動した話
          • 今更ながらGit rebaseの挙動をちゃんと理解して使えるようになる試み

            TL;DR 最近チーム内で、mergeではなくrebaseを推奨する動きが出てきたので、この機会に rebase の動きをちゃんと理解しておこうという足跡です。 merge の動きを確認する まず、merge_aというブランチを作成し、一つコミットを作ります。 次にmerge_bというブランチを作成し、一つコミットを作ります。 再びmerge_aブランチに戻り、一つコミットを作ります。 ここで、merge_aにmerge_bをマージします。 すると以上のようにマージコミットが作成され、コミットの時系列の順にブランチが並びました。 rebase の動きを確認する まず、rebase_aというブランチを作成し、一つコミットを作ります。 次にrebase_bというブランチを作成し、一つコミットを作ります。 再びrebase_aブランチに戻り、一つコミットを作ります。 ここで b をベースにリベー

              今更ながらGit rebaseの挙動をちゃんと理解して使えるようになる試み
            • git rebaseが捗るオプション紹介 - madokaのブログ

              git rebaseでfixupやsquashをよくつかうわたしが出会って感動したオプションたちを紹介してこうと思います。 rebase.autostash git rebase を行うとき、編集差分がある状態では実行できないため、stashして下さいてきなコメントが出てやり直しとなってしまうのが、なんとも面倒臭いと思うのです。 これを払拭するのがautostashです。 git rebase を実行した際に自動でgit stashを行い、rebaseの作業に移ります。そして、rebase作業が終わった際にはstashしたものを戻すgit stash popまでを自動でやってくれるというものです。ぜひ、おすすめしたい、、! rebase.abbreviateCommands git rebase -i で作業するとき、毎度出てくるこの画面。 pick 5f818fa edit file p

                git rebaseが捗るオプション紹介 - madokaのブログ
              • [小ネタ]git rebaseでコミットをまとめる | DevelopersIO

                gitは大切です。とっても大切です。でも難しいです。 今回は、terminal上でgit rebaseを使用してコミットをまとめようとした際にハマったのでまとめます。 git rebaseでコミットをまとめる手順 以下の手順でコミットをまとめます。 git rebase -i HEAD~nコマンドの実施 (n個前のコミットから修正対象) viが立ち上がるので、まとめるコミットをpick -> fixupに修正する viを上書き保存して終了する(:wq) コミットをまとめる では実際にコミットをまとめてみます。 コミットログを確認 rebase_check.pyという足し算を行うpythonファイルを準備します。 rebase_check.py a = 2 b = 3 result = a + b print(result) git logコマンドを使用しrebase_check.pyのロー

                  [小ネタ]git rebaseでコミットをまとめる | DevelopersIO
                • git rebase -iとgit rebaseをちゃんと理解する - 自分用メモ

                  git rebase -iコマンドについてのメモです。 これまで、単に直前のnコミットをくっつけたり消したりして整理できる便利コマンドとして $ git rebase -i HEAD~n と叩いていましたが、なぜこれがrebaseなのかを理解していませんでした。 自分のこれまでの理解が狭かったという話で、同じような状況の方がどれだけいるのかわかりませんが、もしかすると役に立つかもしれないのでメモを書いてみます。 git rebaseで何が起こるのか まず、git rebaseすると何が起こるかを理解しました。 そのためにちょっと腰を据えて https://git-scm.com/docs/git-rebase#_description を読んでみると、git rebase <upstream>は以下のことをすると書いてあります: 現在のブランチにはあるが、<upstream>には無いコミッ

                    git rebase -iとgit rebaseをちゃんと理解する - 自分用メモ
                  • git rebase --rebase-margeについて - Qiita

                    対象 gitでrebaseをよくするし、mergeはマージコミットを残す人。 rebaseするとmergeのマージコミットの記録が失われるのが困る人。 概要 付け替えたいブランチの先端を作業コピーにして以下を実施 git rebase --rebase-merge <付け替え先> -i git rebase --rebase-merge <付け替えたいブランチの根本> --onto <付け替え先> -i git rebase --rebase-merge=rebase-cousins <付け替え先> -i なるべく -i をつけてTODOリストを表示し、作業内容を確認する。 --rebase-merge とは By default, a rebase will simply drop merge commits from the todo list, and put the rebased

                      git rebase --rebase-margeについて - Qiita
                    • git のブランチを別のブランチへ付け替える (git rebase --onto)

                      git-rebase--onto-tldr.md git のブランチを別のブランチへ付け替える (git rebase --onto) たまに --onto を使おうと思うと忘れているのでメモ. 基本(普通に rebase) これを %%{init: { 'gitGraph': { 'rotateCommitLabel': false, 'mainBranchName': 'develop' }, 'themeVariables': { 'commitLabelFontSize': '18px' } } }%% gitGraph commit id: "A" commit id: "B" commit id: "C" branch branch1 checkout branch1 commit id: "D" commit id: "E" commit id: "F" checkout d

                        git のブランチを別のブランチへ付け替える (git rebase --onto)
                      • 【Git】git rebase(リベース)でconflict(コンフリクト)が発生したファイルの修正方法をわかりやすく解説|エラー対処法:CONFLICT (content): Merge conflict in & error: Failed to merge in the changes.

                          【Git】git rebase(リベース)でconflict(コンフリクト)が発生したファイルの修正方法をわかりやすく解説|エラー対処法:CONFLICT (content): Merge conflict in & error: Failed to merge in the changes.
                        • gitのコミットの歴史を改変する(git rebase) 1 / 2 · けんごのお屋敷

                          git には rebase というとても便利なコマンドがあります。その中でも特に便利なのが -i または --interactive オプションです。便利なのですがよく忘れるのでまとめもかねてこの記事で詳しく紹介します。 前提 この記事では説明のために以下のようなコミット状態である前提で話を始めます。よくあるコミットの流れです。 git rebase -i -i は --interactive とあるように、対話的に rebase が実行できるコマンドです。これでなにが出来るかというと コミットメッセージを編集する コミットをまとめる コミットを分割する コミットの順番を移動させる コミットを削除する など、いろんなことが出来ます。基本的な構文は [kengo@tkengo-mac] $ git rebase -i <commit> これだけ。 <commit> には特定のコミットを指定し

                          • git rebaseでconflictした際の対応をシンプルに確認 - Qiita

                            概要 下記のように、ある地点からfeatureブランチを切って開発を進めている間に、masterブランチにもcommitが行われるような状況はよくあると思います。 この状況にて、featureブランチからPRを出すときには、feature側にてmasterの先頭から変更コミットを生やすようにすることが多いと思います(fast-forward?)。 このときmasterのコミットとfeatureのコミットがコンフリクトした場合のgit rebase --continue、git rebase --skipの挙動を確認していきます。 状況 下記のようなgit logの状況から、featureブランチ側でgit rebase masterをしていきます。 target1 in feature、target2 in featureのコミットはmasterのコミットとコンフリクトしています。 tar

                              git rebaseでconflictした際の対応をシンプルに確認 - Qiita
                            • [git] rebaseが完了できない現象("--continue"を飛ばしてしまったため)の解消手順 - Qiita

                              rebaseでハマりました。 自力でなんとか解消できたのですが、ネットで情報を探せずに苦労したのでシェアします。 認識違いがありましたらコメントください。 現象 rebaseでコンフリクトが発生して、手作業で解消して、git rebase --continueを実行したら、以下のようなレスポンスが… $ git rebase --continue Applying: {コメント} No changes - did you forget to use 'git add'? If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch. When you have resolved

                                [git] rebaseが完了できない現象("--continue"を飛ばしてしまったため)の解消手順 - Qiita
                              • git rebase -iでsquashしすぎてしまった時に元に戻す

                                B! 3 0 0 0 git rebase -iでコミットをまとめすぎてしまって元に戻って やり直したい、と思った時にどうやるか。 git reflogを使ってコミットを確認して戻す git reflogを使ってコミットを確認して戻す こんなGitのコミットがあるとします。 $ git log --oneline 03cf5a4 (HEAD -> master) commit 10 84d8c6c commit 9 46bf42c commit 8 3d8d4f2 commit 7 cc1a120 commit 6 512dcb6 commit 5 a3b1556 commit 4 4cce44d commit 3 b3c25fc commit 2 dcc7245 commit 1 f40706d test commit ここでcommit 7までのコミットをまとめたいとします。 reba

                                  git rebase -iでsquashしすぎてしまった時に元に戻す
                                • git rebaseを初めて使った際のまとめ - Qiita

                                  環境 とくになし はじめに 今までrebaseを使ったことが無かったのですが、コードレビューを依頼した際に「マージコミットが邪魔で見づらい…」と言われてしましました。「ログを綺麗にするため」にrebaseについて学んだことのまとめです。 まず、ログがどのように綺麗になるのかを以下に説明します。 mergeを使った場合のログ(あまり綺麗ではないログ) 例えば下図のようなブランチが存在し、自分が今featureにいるとします。この状況でbugfixが入った最新のdevelopを取り込みたいと考えているとします。 マージを使って取り込みます。 無事取り込むことができました。しかし「git log」をしてみると時系列順に並ぶためfeatureのコミットが飛び飛びになってしまい、すごく見づらくなっています。 rebaseを使った場合のログ 最初の状況は先程と同じです。 rebaseを使って取り込んで

                                    git rebaseを初めて使った際のまとめ - Qiita
                                  • Git rebase 〜コミット履歴を綺麗にする技術〜 - Qiita

                                    はじめに ミライトデザイン Advent Calendar 2022 16 日の記事です。 昨日は ほげさんの 図解 DB インデックス でした。 データベースのインデックスについて図解で丁寧に書かれてます。 最近はあまり大きいデータに触る機会も少なく遅くなったらインデックス適当に張るか〜とふんわりとやってたのでこの機会に読んでとても学びになりました。 ほんと図解が超丁寧なのでこういう記事が書けるようになりたいです。 ほげさんほどではないですが、今年のアドベントカレンダーは気合を入れて書き上げました💪 今回はハンズオン形式でgit rebaseをマスターします💪 Gitシリーズ記事まとめ Git rebase 〜コミット履歴を綺麗にする技術〜 😈 あなたのコミット汚れてない? $ git log --oneline c1aa188 (HEAD -> topic-1) テストを実装し直

                                      Git rebase 〜コミット履歴を綺麗にする技術〜 - Qiita
                                    1

                                    新着記事