当git指向本地时更新master

时间:2013-11-26 00:09:21

标签: git github

我对Git非常陌生,我觉得我有点理解Git,直到我再碰到另一面墙。

我甚至不确定我是否在问正确的问题,但请耐心指导或指导我。这就是我现在所拥有的:

  1. 从Git repo拉入Master分支
  2. 做了一些改变
  3. 创建一个新的'temp'分支并将其更改提交给它并推送它进行代码审查(不与Master合并)。 Git branch --list现在显示我指向'temp'分支。
  4. 尝试启动与代码相关的服务,并且它引入了最新的依赖项,导致我的IDE中的编译错误(之前正在运行)
  5. 以下是我的问题:

    1. 我想对主人做一个git pull。现在git指向我的本地存储库,我担心如果我做'git pull'它会覆盖我的更改。有没有办法让我更改我的分支以掌握并更新它而不会丢失我的更改?

    2. 一旦我能够切换到Master并拉出最新的,我认为新代码将起作用(除了我的更改不会在那里)。要包含我已经在代码审查中的更改,我是否需要重新执行Master中的所有操作并再次提交?我在这里的工作流程中迷失了方向。当Master不断变化并且不得不重构你的工作时,拥有一个本地分支只是不好的做法吗?

    3. 我确信我的理解存在脱节,所以我将不胜感激。

      由于

3 个答案:

答案 0 :(得分:0)

对于Q1 要检查主分支,请执行git checkout master(在结帐主数据之前,您可以在临时分支上运行git status以确保您的工作区是干净的)。进入主分支后,您可以执行git pull以将服务器端的主服务器的最新更改发送到本地存储库。

对于Q2 虽然您可以逐个手动地在master上手动应用所有更改,但您不应该这样做。因为这将改变对temp分支的局部更改的提交,这可能导致代码审查系统将它们作为总新提交(通过差异完全相同)。 如果你只是想知道如果结合最新的主变更和本地临时分支它会是什么。您可以: git checkout temp git checkout -b temp_with_master#从temp创建一个新的测试分支 git merge master#merge master的更改 取笑 git checkout temp git branch -d temp_with_master#finally,删除测试分支

答案 1 :(得分:0)

不确定我是否正确理解了问题。如果您的更改仅在您的本地临时分支上进行,那么拔出母版时应该没有问题。

使用

更改为主分支
git checkout master

并拉上主人

git pull origin master

(如果它不是原点,请查看git remote -v)

您的其他分支的更改不会丢失。在您提交或隐藏更改之前,Git不会让您更改分支。

对于提交我建议

git citool

如果您还没有使用它。

当主分支不断变化时,拥有本地分支没有问题。虽然如果它不断变化我会称之为发展,而不是主人。但这可能取决于......

您无需重做主人的所有内容。你需要的是一个git merge。

使用git checkout master更改为master分支,并将本地temp合并到其中。

git merge master temp

这可能会导致冲突 - 如果有人更改了您已更改的相同行,则必须解决这些冲突。但是你会被git告知你。

答案 2 :(得分:0)

对于1.)是的,这是可能的。如果您仍在进行未提交的更改,请在进行更改之前继续提交它们(例如更新其他分支)。你可以随时再次回到你的'临时'分支,如果你没有完成,甚至可以通过更多修改来“修改”它。 (git stash也是一个许多人认为对此有用的命令)。所以,你要求的是这样的:

> git commit -a -m "stashing my changes"
> git checkout master
> git pull origin
> git checkout temp

然后,您已使用“origin”(这是远程服务器的默认名称)的最新更改更新master到master分支,并且您恢复了temp,并且所有更改都保持不变。

回答2.)在某种程度上取决于项目本身建立的工作流程。这两个选项是merge和rebase,它解释了每个选项的优缺点让人感到困惑。

如果评论不是很重要(只是该功能有效,通过测试等),那么有些人将master合并到temp(有时几次在你的分支中开发功能)和当它准备就绪时,请求将分支合并回主节点。这有点类似于SVN工作流,您可以定期更新工作树,并且只在完成时提交。但是,在这种情况下,使用git会有更多的提交,因为每次合并都会记录下来,并且查看所有更改变得更加困难。

(hack, hack, hack, commit to temp)
> git fetch origin
> git merge origin/master
(resolve merge conflicts)

第二个选项是rebase,您可以在更新的master版本之上重做所有更改。 Git将尽可能自动化,并在遇到问题时停止(处理与合并冲突相同)。

(hack, hack, hack, commit to temp)
> git checkout master
> git pull
> git checkout temp
> git rebase master
(resolve merge conflicts)

您也可以多次执行此操作(在新版本的master上更新master,rebase)。完成后,再次请求将结果提取到master中。优点是项目维护者通常更容易查看,缺点是它现在与已经审核但未合并的第一版“temp”无关。