GITのリベースコマンドでコンフリクトが起きたときの表示について

投稿者: Anonymous git bashでリベースコマンドでmasterブランチの内容をfeatureブランチへマージすると コンフリクトが起きたので対応してgit continueしたのですがまたコンフリクトの表示が でます。「feature|REBASE 3/20」という表示もあるのですがこれはどういう意味を 指すのでしょうか。20/20になるまでコンフリクトの対応をし続けないといけないので しょうか。 解決 feature|REBASE 3/20 という表示であるということはマージではなくrebaseを行っていて、”git continue”というのは git rebase –continue のことだと解釈しました。 「feature|REBASE 3/20」という表示もあるのですがこれはどういう意味を指すのでしょうか。 オフィシャルな説明は見つけられなかったのですが、初回conflictが発生した箇所以降全部で20コミットがあり、今回処理しようとしているコミットはそのうち3つめである、という意味だと思います。 20/20になるまでコンフリクトの対応をし続けないといけないので しょうか。 状況によりますが、最悪だとその通りです。最善の場合はそのconflictを解消すれば残りは何も対応せずにrebaseが成功します。 似たような状況を再現するスクリプトを作ってみました。 #!/bin/bash mkdir repo-conflict pushd repo-conflict git init git commit –allow-empty -m init echo ‘hello, world’ > hello.txt git add hello.txt git commit -m ‘hello’ git checkout -b feature for…(Continue Reading)

Git – Borrar archivos con rm (no con “git rm”) y reflejarlo en el index, el repositorio local y el repositorio remoto

publicado por: Anonymous Hace unos días comencé a estudiar Git. He comprendido todo bastante bien, aunque tengo algunas dudas respecto a cómo borrar archivos. Precisamente, lo que quiero saber es cómo borro un archivo/directorio con el comando “rm” de linux y que ésta acción no sólo se vea reflejada en el index (stage), sino también…(Continue Reading)

TortoiseGitでメールアドレスが設定出来ない

投稿者: Anonymous gitを使用するために、TortoiseGitをインストールしましたが、設定が上手く行きません。 デスクトップで右クリックから、TortoiseGitの設定画面を開き、Gitを選択、名前の入力までは出来ましたが、メールアドレスが入力出来ません。 そのまま設定画面を閉じてcommitしようとしてもメールアドレスが設定されてないとエラーが出ます。 環境はWindows10 Homeです。 解決 編集対象の選択 設定画面の上部に「設定のでどころ(Config source)」という選択項目があります。 ここで、編集する対象を適切に選ぶ必要があります。 「ローカル(Local)」がプロジェクトディレクトリの.git/config に 「グローバル(Global)」が ユーザーのホームディレクトリの .gitconfig に 「システム(System)」がシステム共通の設定である /etc/gitconfig に 「有効値(Effective)」はそれらを優先度順に読み込んだ結果として決定された値(つまり編集する物ではない)に 対応しています。 プロジェクト間で共通のメールアドレスを設定する、という事でしたら「グローバル」です。 このプロジェクト(ディレクトリ)にだけ設定したい、という事ならば「ローカル」です。 インストール時の設定 質問者さんが再インストールで解決したのは、インストール時にユーザ情報を聞かれた際に、設定ファイルに反映するチェック欄を有効にしたためと思われます。 ここでこの選択をすると、入力したユーザ情報は「グローバル」、つまりユーザーのホームディレクトリの.gitconfig に書き込まれます。 ですから、後からこれを変更する場合は「グローバル」を選択し、編集する事になります。 回答者: Anonymous

¿Cómo puedo hacer git pull después de un cambio en la historia en el remoto?

publicado por: Anonymous Si otro desarrollador hizo un cambio en la historia de git y luego hizo git push -f, git pull no me funciona. ¿Cómo puedo traer los cambios del remoto? solución Traducido de git pull after forced update El primer paso es recibir todos los commits que están en el remoto, para eso…(Continue Reading)

git log –helpで読めるヘルプの-ccオプションについて

投稿者: Anonymous git log –helpで読めるヘルプの-ccオプションについての説明で理解し切れないところがあります。 “omitting hunks whose contents in the parents have only two variants” “merge result picks one of them” 1に関して:「マージ後とその親の間で、変更点が2つ以下のhunkは省略しますよ」という理解でよいのでしょうか? 2に関して: “them”が何を指しているのか、また、マージ後のcombined diffを見ようとするためのgit log –ccで、どうしてマージ結果はthemのうち1つを”選ぶ(?)”ということになるのか(マージ結果は確定しているのでは?)、という2点が分かりません。 解決 興味があったので調べてみました。私の解釈として回答させて下さい。 ちなみに私は英語は母国語ではないので、そこは割り引いて下さい。 git log –help の該当する –cc の部分の内容は多分2008年以降変わっていないと思うので (最終更新) 以下に引用して、整形・括弧書きを追加しました。 This flag implies the -c option and further compresses the patch output by omitting uninteresting hunks…(Continue Reading)

gitで異なるコミットリビジョンの異なるファイルをDIFFするには?

投稿者: Anonymous 異なるコミットリビジョンの同一ファイルは、DIFFできることを知っているのですが、 renameなどでファイルパスが変わったコミットとその前のコミットで、 ファイルのDIFFをする方法はありますか? 解決 Git2.9よりリネーム検知がデフォルトで有効になりました。 The GitHub Blog より: Rename detection is now enabled by default for diffs.[中略] Git infers on the fly when a file has been renamed by looking for similarities between the contents of the old and new files. 従って最近のバージョンであれば git diff HEAD~2 のような実行で所望の結果になっていると思います。 特定のファイルの差分が知りたい場合には、依然としてリネーム前のファイル名も指定する必要がありそうです。 git diff HEAD~2 HEAD —…(Continue Reading)

git push が反映されない

投稿者: Anonymous Vagrant上のローカルリポジトリから,リモートのリポジトリに $ git push をしたときに,$ git log 上ではコミットメッセージが表示されるのに,リモートのファイルに変更が反映されません.なぜでしょうか? 解決 まず: vagrant はあんまり関係ないと思います。一般化して、 CUI 上の unix 環境において、以下の方法が有効かと思います。 今、問題になっているのは、「git push (したと思っていて、手元で git log を実行したところ commit メッセージがちゃんと表示されているにもかかわらず) リモートのブランチに反映されていない」ことだと理解しました。ひとまず、 git log –graph –abbrev-commit –decorate –format=format:’%C(bold blue)%h%C(reset) – %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)’ –all (https://stackoverflow.com/questions/1057564/pretty-git-branch-graphs より引用) をローカルで実行してみてはいかがでしょうか。上記を実行すると、わかり易い情報の git log –all が取得できます。gitk や Source Tree などの GUI…(Continue Reading)

Git 不要になったローカルリポジトリの削除方法は?

投稿者: Anonymous Git 初心者でございます。 ローカルリポジトリの作成は… git init で作成しました。 さて、プロジェクトが終了し、不要になったローカルリポジトリは、どのように削除するのでしょうか? 解決 $ git status で、コミット漏れがないか、名残惜しいものがないか確認して $ git fetch $ git log -1 $ git log -1 origin で二つのログを比較してプッシュ漏れがないか(相違がないか)確認して $ cd .. $ rm -rf {レポジトリ名} で、ディレクトリを消去。 ( git を使ったことによる特別な要素はトップにある .git ディレクトリだけです。) 回答者: Anonymous

Git のフックスクリプトで、単なる commit か merge commit かを区別出来るのか?

投稿者: Anonymous 実現したいことは、あるブランチで直接 commit することを禁止し、他のブランチからの merge commit のみを許すことです。例えば、 Gitflow で運用した時に develop ブランチへの直接 commit を禁止して、 feature や release ブランチなどからの merge commit だけを認めることを開発メンバに強要したいといったケースです。 コミット前にチェックするための仕掛けとして pre-commit フックを使うのが最も自然だと思うんですが、実行されたのが commit か merge –no-ff による merge commit かをフックスクリプト(hook scripts)の中で区別する手段ってあるんでしょうか? もしくは pre-commit フックを使わずに上記を実現する方法はあるんでしょうか? 解決 pre-commit フックを使用しない方法はちょっと分からないので,素直に pre-commit フックを使用した方法を示します. develop ブランチへの commit を禁止するには, .git/hooks/pre-commit を #!/bin/sh # Redirect output to stderr. exec 1>&2…(Continue Reading)

Gitで環境毎の設定ファイルだけ、途中から管理対象外(ファイルを残す)とする方法

投稿者: Anonymous 現在、Gitで実装中のソフトを複数環境で運用したいと考えております。その際、環境毎にデータの保存先や参照するパスの情報が変わって来るので、Gitの管理対象からは外して運用したいと考えています。 この場合、.gitignoreにそのファイルを加えてしまうと、ファイル自体が消えてしまったのですが、今までのコミットの情報は残しつつ、今後のGitの管理からはそのファイルを管理対象から外すという事は出来ないのでしょうか? 解決 今までのコミットの情報は残しつつ、今後のGitの管理からはそのファイルを管理対象から外すという事は出来ないのでしょうか? git rm –cached FILE コミットすると、リポジトリの中の 設定ファイルを消すことになります。 開発者がコミットしつつ 設定変更する用途には利用できません。 git update-index –assume-unchanged [ファイル名] git update-index –skip-worktree [ファイル名] どちらも 開発者が 自分の修正を間違ってコミットしないように 変更の追跡を逃れる目的で利用します。 開発者が 各自の作業ディレクトリで このコマンドを実施する必要があります。 中央のリポジトリで 設定ファイルが変更された場合、その設定を 自分の環境に上書きするか? 無視するかの違いによって この2つのコマンドを使い分けます。 の案がありますが、おそらく どちらも 目的通りには動作しないと思います。 git 初心者が 開発者の中にいると間違ってコミットする・・という事が良くおきます。 根本的な解決 環境定義を読み込む部分で、複数のファイルから値を読み込むような工夫が必要だと思います。 1)すべての環境で共通の設定が入った物:ソース管理する。 2)開発時の設定によって設定が変わる物:開発版、リリース版で違う定義にする。ソース管理する。 3)個人の開発環境によって設定が違うもの:ひな形だけソース管理する。   各個人は ソース管理外のフォルダにおいて自由に変更して利用する。 これらの設定をアプリが読み込むようにアプリ側で工夫をします。 dotnet Core であれば ユーザーシークレット と言って 環境に依存する設定は 複数の設定ファイルや、環境変数から読み込んでその値を利用するようになっています。…(Continue Reading)

¿Por qué Git no reconoce mi contraseña? (Permission denied)

publicado por: Anonymous Cuando ejecuto git pull me pide la contraseña, la ingreso pero no la reconoce. El problema radica en que no me pide la contraseña de mi usuario o mi clave pública, me pide el usuario git por defecto, o al menos pienso eso. Por ejemplo: $ git pull origin2 release_2.0 [email protected]’s password:…(Continue Reading)

Regresar un repositorio a un commit especifico

publicado por: Anonymous Basado en ¿Cómo puedo deshacer el último commit en Git?. ¿Hay alguna forma de regresar un repositorio Git a un commit en espeficico?. Por ejemplo: commit a “Primer commit” commit b commit c commit d commit e commit f commit g commit h “Versión actual” ¿Hay forma de regresar al “commit c”?.…(Continue Reading)

ブランチの切替について

投稿者: Anonymous ブランチの切替について質問です。 eclipseで操作をしているのですが・・・ ローカルリポジトリでmasterブランチから作業ブランチを作成し、作業ブランチでAファイルを編集中、最新状態へ更新する必要が出てきました。(作業ブランチの変更内容は除いて) masterブランチに切り替えたのですが このとき、コミット、ステージングをしていないのに問題なく切り替えることができました。 その代わり、作業ブランチで変更した内容がmasterブランチに反映されていました。 競合が発生しない場合は変更内容が維持されてブランチが切り替わるのでしょうか? ≪理想≫  作業ブランチ ・・・ AファイルにZを追加中  ↓切替 masterブランチ・・・ AファイルにはZの内容はない ≪現実≫  作業ブランチ ・・・ AファイルにZを追加中  ↓切替 masterブランチ・・・ AファイルにはZの内容がある   現在この現象のせいで、作業ブランチでの編集中の内容を含めてmasterブランチにPUSHされてしまいました・・・。 この場合、ブランチを切り替える際は必ずコミットをするという運用にするしか回避する方法は無いのでしょうか? 初歩的な質問となりますが、ご教授お願いします・・・。 解決 競合が発生しない場合は変更内容が維持されてブランチが切り替わるのでしょうか? その通りです。 この場合、ブランチを切り替える際は必ずコミットをするという運用にするしか回避する方法は無いのでしょうか? git stashで一時的に変更を退避するというのが解決策になるかと思います。 また、今回の事象はブランチ切替時にリポジトリの状態を確認していれば防げた事だと思われますので、git statusで状態を確認する癖をつけるというのが大事な気がします。 回答者: Anonymous

gitでpush前にローカルのcommitをまとめたい

投稿者: Anonymous リモートリポジトリをcloneし、ローカルでトピックブランチを切ってそこで開発をしています。 ちょっとした機能の完了や一日の終わりといったタイミングでちょくちょくコミットしているのですが、 リモートリポジトリにpushする前にトピックブランチのコミットを1つにまとめて 「1タスクの完了」という粒度にしたい場合のベストプラクティスを教えて下さい。 またトピックブランチでの開発完了のみならず「そろそろまとめとくか」というタイミングで ブランチ内の幾つかのコミットを1つにまとめる、という使い方がしたいと考えています。 rebaseだとトピックブランチが統合されて消えてしまう為使えませんでした。 解決 ベストプラクティスというか、「ローカルのコミットを操作する方法」はそもそもいくつか存在します。今回のケースにで一番使いやすいのは rebase だと思います。 rebase だとトピックブランチが統合されてしまうということですが、多分こんな使い方をしたのではないでしょうか。 # トピックブランチ上で git rebase develop そうではなくて、 git rebase -i $(git merge-base HEAD develop) で、「interactive な rebase 」を起動し、最初のコミット以外を “squash” すれば、やりたいことは達成できると思います。そのやり方は、検索すればいくらでもでてくるとはおもいますが、たとえばこのページ などはどうでしょうか。 ただ、そこまで git の操作に自信がない、ということでしたら、そもそもコミットするタイミングで、 git commit –amend でもってコミットして、「直前のコミットを直に書き換える」ことを繰り返していく方が、解りやすいかとは思います。 回答者: Anonymous

¿Por qué no es posible almacenar un directorio vacío en git?

publicado por: Anonymous Como dice el titulo: ¿Por qué no es posible almacenar un directorio vacío en git? Por ejemplo, en un repo nuevo: $ mkdir foo $ git add foo $ git status On branch master Initial commit nothing to commit (create/copy files and use “git add” to track) El directorio vacío foo, no…(Continue Reading)

git で指定ファイルのプロジェクトルートからの相対パスを取得したい

投稿者: Anonymous エディタで git 管理されているファイルを見ているとき、このファイルが git のルートディレクトリからの相対パスが、一体どうなっているのか気になりました。 指定されたパスのファイルが、 git のルートからの相対パスがどうなっているかを取得するコマンドなどはありますでしょうか。これができると、たとえば github 上の該当ページを open する、といったような、もろもろのスクリプト作成が可能だろうと思い、質問しています。 解決 少し、調べたらでてきたので自己回答します。 git ls-files –full-name committed-file とやると、committed-file というファイルの、 git ルートからの相対パスが取得できました。 回答者: Anonymous

git stash -> git commit –amend -> git stash pop の流れをスムーズに行いたい

投稿者: Anonymous コミットメッセージを修正するのに、 git stash -> git commit –amend -> git stash pop するのが面倒です。 なにか良いアイデアはないでしょうか? 解決 個人的には commit –amend 自体そこまで頻繁に使うものではない上、git stash pop の動作は git stash を実行したときスタックに詰むべき変更があったかどうかで変わってしまうのであまりオススメできませんが、一応一連の動作を Git エイリアスを使ってひとつのコマンドにまとめることができます。 [alias] stashamend = !git stash && git commit –amend && git stash pop 回答者: Anonymous

同一ブランチを複数人で作業している際の競合に関して

投稿者: Anonymous 複数人が同一ブランチで作業をしていて、共有ファイルでよく競合が発生してしまいます。 作業IDEはECLIPSEです。 マージツールなどで競合の解決をしているのですが、そうなるとコミットログが複数発生してしまいます。 赤枠の部分を1つのコミットとしてまとめたいと思うのですが、そのようなことは可能でしょうか? 操作手順は・・・ (私)ローカルリポジトリでAファイルを作業 (別の人)がAファイルをリモートリポジトリにプッシュ (私)最新をプルすると競合が発生 (私)Aファイルをコミット (私)競合解消作業をしてコミット(マージツールを使って手動で) (私)引き続き作業 (私)プッシュ完成なのでコミット (私)リモートへプッシュ 8の段階で4と5と7を1つのコミットにまとめたいので対話式リベース(スカッシュ)を試みましたが 出来ませんでした・・・ ※5の手順書き直しました! このような場合、競合解決の方法は私の手順であっているのでしょうか? また図のように複数のコミットをまとめる行為は通常しないものでしょうか? Git初心者で初歩的な質問となっていますが、ご教授のほどおねがいします。 解決 git pullはgit fetch + git mergeを行うので、pullの代わりにgit fetchを使いましょう。 (fetchは履歴情報だけを取得して、自動でのmergeは行いません) pullまたはfetchのどちらを使う場合でも、なるべくリモートからの同期を行う前に作業ディレクトリはクリーンな状態にしておきましょう。 コミット前であればgit stashで退避を 頻繁に競合が発生しそうなら、予め作業ブランチを切っておく 競合が発生した場合には、mergeでもrebaseでも競合箇所がマークされるはずなので、競合した個所を適切に修正すればrebaseでもコミットできるはずです。 (今現在実行されている手順だと、競合が発生した場合に「競合を解消するためのコミット」を作っているということですよね?) 追記 コマンドペースかつ説明のために冗長なやり方になっている部分があるかもしれませんが、rebaseのイメージを掴んでもらえればと思います。 この場合のrebaseは「枝分かれした部分を履歴の先頭に付け替える」ために使用します。 あなたがローカルのmasterでコミット(D)を作成しているうちに、リモートのorigin/masterでも別のコミット(C)が作成され、履歴が分岐してしまったとします。 C origin/master (He) / A—B—D master (You) 自分の作業した分を別のブランチtopicに切り替えます。 $ git checkout -b topic ; git…(Continue Reading)

git でフォルダ (ファイル) ごとにマージストラテジーの使い分けはできるか?

投稿者: Anonymous git で、フォルダごとに異なったマージストラテジーを利用しながらマージを行いたくなりました。 これは、実現できますか? 解決 以下のページで説明されている通り、.git/info/attributesファイル または .gitattributesファイル に設定することができます。 https://stackoverflow.com/questions/14093540/tell-git-to-use-ours-merge-strategy-on-specific-files https://git-scm.com/docs/gitattributes フォルダごとに設定する場合、上記ファイルに [パス]/* merge=[マージストラテジー] と記載します。 例えば、 hoge フォルダ配下のファイルに oursストラテジーを適用する場合、 hoge/* merge=ours と記載します。 サブフォルダにも同じストラテジーを適用したい場合、 [パス]/** merge=[マージストラテジー] と、記載すればOKのようです。 ちなみに上のページの回答にあるとおり、マージストラテジーの中にはデフォルトで無効になっているものがあるようなのでご注意ください。 回答者: Anonymous

¿como puedo retroceder en git a un commit especifico, sin perder algunos datos posteriores?

publicado por: Anonymous Hola buenas quisiera saber ¿como puedo retroceder en git a un commit especifico, sin perder algunos datos posteriores? para restaurarlo ¿es posible? muchas Gracias solución Hola después de buscar y concejos he llegado a una solución agradable: la cuestión es estando en la rama de trabajo tomar el nombre del commit desde…(Continue Reading)

全てのリモートリポジトリをfast-forward可能な範囲で同期したい

投稿者: Anonymous 作業開始前に全てのリモートブランチやタグを完全に同期し、トラッキングしているローカルブランチもfast-forwardできる範囲で同期したいのですが、git pull –all –prune –ff-onlyを実行しようとすると以下のエラーが出てしまいます。 $ git –version git version 2.2.1 $ git pull –all –prune –ff-only error: unknown option `ff-only’ usage: git fetch [<options>] [<repository> [<refspec>…]] or: git fetch [<options>] <group> or: git fetch –multiple [<options>] [(<repository> | <group>)…] or: git fetch –all [<options>] -v, –verbose be more verbose … やりたいことは、 全てのリモートリポジトリについて、リモートブランチとタグを、削除も含めて完全に同期する…(Continue Reading)

gitのマージを含むコミット履歴の整理

投稿者: Anonymous 以下のような git のコミット履歴があります。 <現状> * ローカルコミット7 * ローカルコミット6 * ローカルコミット5 * マージ | | * リモートコミット3 | * リモートコミット2 | * リモートコミット1 | | * | ローカルコミット4 * | ローカルコミット3 * | ローカルコミット2 | | |/ | * ローカルコミット1 | … git log を見やすくする目的で、以下の<A>もしくは<B>のようにコミットをまとめたいと考えています。どのようにすればいいでしょうか。 <A> * マージ+ローカルコミット5〜7 | | * リモートコミット3 | *…(Continue Reading)

¿Cómo puedo renombrar un repositorio?

publicado por: Anonymous Tengo un repositorio en GitLab con un nombre repo. Estoy trabajando con él en local tras hacer un: git clone [email protected]:yo/repo.git Ahora decidí cambiarle el nombre a repo_nuevo y así lo hice desde la interfaz de GitLab. Esto quiere decir que a partir de ahora para inicializarlo debo hacer: git clone [email protected]:yo/repo_nuevo.git…(Continue Reading)

Gitで2つのリポジトリを統合したい

投稿者: Anonymous どうにも困っておりまして、質問させていただきます。 現在、違うサーバにAというリポジトリと、Bというリポジトリがあり、これをAのサーバに統合したいのですが、 A–.git  |–develop–B–.git        |-home としたときに、BがAのリポジトリに認識されず、commit,pushした後、別の端末でAをクローンすると、 A–.git  |–develop–B となり、Bの中身を取得することができませんでした。 別のリポジトリだからだと思い、git remote set-urlでリモートリポジトリを変更したのですが、効果がありませんでした。 履歴を残す必要があり、以下の記事を読んだりしたのですが、どのようにすればよいのかわかりません。 https://chaika.hatenablog.com/entry/2015/06/04/173401 どうかご教授お願いいたします。 解決 git リポジトリの中に git repository を物理的に配置した場合、それは git submodule が実体化されたものであると認識して動作するようになっています。 submodule は、端的に言えば、ディレクトリ構造をコミットするかわりに別リポジトリのコミットの sha-id のみを記録しておく機能です。 submodule ではなく、 git の履歴自体を取り込みながら、とある統合コミットがあって、それは二つのリポジトリの歴史のマージコミットであり、一方がもう一方のサブディレクトリに配置されているようなことが実現したい場合、これは git subtree を用いるのが良いです。 git subtree add –prefix=サブディレクトリへのパス リモート ブランチ で実行します。 具体例 準備スクリプト #!/bin/bash rm -rf A mkdir A ( cd A…(Continue Reading)

Crear rama a partir de otra mediante comandos (git)

publicado por: Anonymous Dentro de mi proyecto estoy realizando unas tareas en una rama (rama_A), que fue ramificada de la rama principal del proyecto (master). Ahora necesito crear una nueva rama, que nazca a partir de la rama_A (pongamos rama_A_ramificación) ¿Cómo puedo crear una nueva rama a partir de otra ya creada con comandos? Cuando…(Continue Reading)

.gitignore no funciona ignorando una subcarpeta de una carpeta ignorada

publicado por: Anonymous he intentado implementar las soluciones de: https://stackoverflow.com/questions/5533050/gitignore-exclude-folder-but-include-specific-subfolder/ sin exito. Con lo siguiente en el gitignore, no ignora ninguna subcarpeta ni a node_modules, ejemplo de mi archivo : !node_modules/ node_modules/* !node_modules/node-dht-sensor-chip/ node_modules/* node_modules/* !node_modules/node-dht-sensor-chip/ !node-dht-sensor-chip/ !node_modules/node-dht-sensor-chip/ !node-dht-sensor-chip/* !*node-dht-sensor-chip/ Con lo siguiente ignora todo de la carpeta node_modules, incluida node_modules node_modules/ **/node_modules/* !**/node_modules/node-dht-sensor-chip/ solución…(Continue Reading)

コミット履歴を変更したmasterブランチに対してリベースしたい

投稿者: Anonymous 以下のようなブランチで作業しています。 bugfix1ブランチでの作業が終わったので、masterブランチに取り込みます。 ただ、bugfix1のコミットはmasterブランチの先頭コミットと1つにまとめたいです。 しかし良い方法が思いつかず、以下のような無駄の多いであろう手順で行いました。 特にmasterブランチを一度削除している部分は「なんか違う」と感じます。 もっと短い手順で行う方法はありますでしょうか? 現在の状態は以下の通りとします。 git log –oneline –graph –all –decorate * 557ceac (HEAD -> bugfix1) C4 * 4c8dea5 (develop) C3 * fb1dc6b (master) C2 * 65947d3 C1 * e91df3b C0 手順1. C4の分岐元をC2に変更します。 git rebase –onto master develop bugfix1 * db81c6c (HEAD -> bugfix1) C4 | * 4c8dea5 (develop) C3 |/…(Continue Reading)

gitなどでコンフリクトしたときの記法の名前を知りたい

投稿者: Anonymous git や hg でmergeがコンフリクトしたとき、ファイルが以下のような内容になるかと思います。 この <<<<<<<, ========, >>>>>>> を用いた記法に名前はあるのでしょうか。 … <<<<<<< HEAD hoge ======= fuga >>>>>>> develop … 解決 git-merge のマニュアル内 TRUE MERGEセクション、CONFIGURATIONセクションでは “conflict marker” と呼称されています。 回答者: Anonymous