【问题标题】:Managing local-only changes with git使用 git 管理仅本地更改
【发布时间】:2011-11-24 20:37:12
【问题描述】:

在我的本地分支上,我对 Makefile 进行了一些个人(仅限本地)更改(只是更改了编译器的路径)。显然我不想提交这些更改,因为它们只与我相关。但是,如果我不提交它们,那么当我尝试与远程分支同步时会出现错误:

% git fetch upstream
% git merge upstream/master
error: Your local changes to 'Makefile' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.

每次发生这种情况时,存储然后取消存储文件似乎很乏味。例如,在 Perforce 上,您只需将这些文件移动到单独的更改列表并在必要时解决合并冲突。

我希望 git 自动将我的本地 Makefile 与远程 Makefile 合并(如果可能),但不必提交它。我该怎么做呢?

【问题讨论】:

  • 为什么不让 git 忽略 makefile?
  • @dasheddot:我不想忽略该文件。如果有人向 makefile 添加了新命令,那么我仍然希望在合并时收到该更改,我只是不想将更改提交到该文件。

标签: git version-control merge git-merge


【解决方案1】:

可能有几种方法可以解决这个问题,这是我的想法。

创建一个新的makefix 分支并在那里提交makefile。每当您需要制作项目时,请切换到该分支。您可以在 master 中工作,然后继续合并,或将 makefix 分支重新定位到 master

一般的想法是,您正在创建一个包含永远不会推送的 Makefile 的分支。

就我个人而言,我会将makefixmaster 相对,因此我的Makefile 更改始终领先于实际的可推送代码。它只是在我的脑海中感觉更干净。

代码示例

git branch makefix
git checkout makefix

Makefile进行更改

git add Makefile
git commit -m "Add Local Makefile Changes to Compiler Path"

日常工作

git checkout master
git fetch upstream
git merge upstream/master

git checkout makefix
git rebase master

又长又丑,希望别人有更好的办法=]

【讨论】:

  • 感谢您的回答。正如你所说,它有点长,所以我希望有人知道一个更简单的解决方案。如果没有简单的方法来管理仅限本地的更改,我会感到非常惊讶。
  • 我看到的问题是,您希望 1) 不推送的本地更改,但 2) 领先于跟踪文件的远程版本。你也可以每次都变基你的本地提交,只是注意不要推送 HEAD,但这似乎更容易出错。
  • 当然需要一些命令,但到目前为止,这是处理这个恕我直言的最干净的方法,所以 +1。但是,我会选择 git merge master 而不是 git rebase master:这会使 makefix 分支的旧状态保持不变,在两个分支之间创建一个阶梯,基本上记录了您要发布的所有状态以及所有这些状态应用您的本地更改。
【解决方案2】:

让 git 自动进行 rebase 可能更容易,即创建一个本地分支,配置 rebase,添加你的更改,pull ...

git checkout -b mybranch origin/master
git config branch.mybranch.rebase true

根据您的需要调整 Makefile ...

git add Makefile
git commit -m 'My local-only Makefile.'

从现在开始,git 将重新调整您的更改

git pull

或者,(特别是如果你不能选择变基)你可以创建一个常规 Makefile 的副本来使用和 gitignore:

cp Makefile Makefile.local
echo Makefile.local >> .git/info/exclude
make -f Makefile.local

但是,对于该变体,您需要密切关注(常规的、由 git 控制的)Makefile,并在必要时相应地更新您的本地版本。

【讨论】:

    【解决方案3】:

    为什么不修复 Makefile 以使用变量作为编译器的路径而不是硬编码?然后您可以在您的环境中设置适当的值。其中很多(如 C 编译器的 CC、C 预处理器的 CPP 等,都是由 make 预先设置的)。如果你的不是,你可以给它一个可以被环境变量覆盖的默认值。此示例假设 GNU make,其他 make 实用程序允许类似的解决方案:

    FOO ?= /usr/bin/foo
    
    test:
            @echo CC is ${CC}
            @echo FOO is ${FOO}
    

    (确保使用真正的标签)。

    这给出了:

    $ make
    CC is cc
    FOO is /usr/bin/foo
    $ export FOO=/opt/bin/foo
    $ make
    CC is cc
    FOO is /opt/bin/foo
    $ make FOO=/just/this/once
    CC is cc
    FOO is /just/this/once
    

    这是一个更易于维护的解决方案,并且避免了有一天意外将您的本地更改推送到上游的风险。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-01-23
      • 2022-01-05
      • 2013-09-15
      • 2016-01-05
      • 2013-01-19
      • 1970-01-01
      • 1970-01-01
      • 2017-05-28
      相关资源
      最近更新 更多