从主人进入git中的分支机构

发布于 2025-01-18 23:47:26 字数 189 浏览 4 评论 0原文

在我的存储库中,我有一个叫做aq的分支。

然后,我在Master中犯下了新作品和错误。

将这些提交进入aq分支的最佳方法是什么?从Master中创建另一个新分支,然后将其与aq合并?

In my repository I have a branch called aq which I'm working on.

I then committed new work and bugs in master.

What is the best way to get those commits into the aq branch? Create another new branch out of master and merge it with aq?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(15

倾其所爱 2025-01-25 23:47:26

查看aq分支,然后从master中重新列出。

git checkout aq
git rebase master

Check out the aq branch, and rebase from master.

git checkout aq
git rebase master
猥琐帝 2025-01-25 23:47:26

当你在 aq 分支上时,你应该能够git merge origin/master

git checkout aq
git merge origin/master

You should be able to just git merge origin/master when you are on your aq branch.

git checkout aq
git merge origin/master
落花随流水 2025-01-25 23:47:26

首先检查 master:

git checkout master

进行所有更改、修补程序和提交,然后推送 master。

返回到您的分支“aq”,并将 master 合并到其中:

git checkout aq
git merge master

您的分支将与 master 保持同步。合并的一个很好的基本示例是 3.2 Git 分支 - 基本分支和合并

First check out to master:

git checkout master

Do all changes, hotfix and commits and push your master.

Go back to your branch, 'aq', and merge master in it:

git checkout aq
git merge master

Your branch will be up-to-date with master. A good and basic example of merge is 3.2 Git Branching - Basic Branching and Merging.

等往事风中吹 2025-01-25 23:47:26

不能保证主错误修复不在其他提交中,因此您不能简单地合并。假设

git checkout aq
git cherry-pick commit1
git cherry-pick commit2
git cherry-pick commit3
...

这些提交代表错误修复。

从现在开始,请将错误修复在单独的分支中。 您将能够。

git merge hotfixes

当您要将它们全部滚动到常规开发分支时,

There is no guarantee that the master bug fixes are not amongst other commits, hence you can't simply merge. Do

git checkout aq
git cherry-pick commit1
git cherry-pick commit2
git cherry-pick commit3
...

assuming those commits represent the bug fixes.

From now on though, keep bug fixes in a separate branch. You will be able to just

git merge hotfixes

when you want to roll them all into the regular dev branch.

深海夜未眠 2025-01-25 23:47:26

此(从这里)为我工作:

git checkout aq
git pull origin master
...
git push

引用:

git pull origin master获取并合并了主的内容
分支机构与您的分支机构创建合并提交。 如果有
合并冲突
在此阶段您将获得通知,您必须解决
合并在继续进行之前
。当您准备好推动自己的
本地提交(包括您的新合并提交)到远程服务器,
运行git push

This (from here) worked for me:

git checkout aq
git pull origin master
...
git push

Quoting:

git pull origin master fetches and merges the contents of the master
branch with your branch and creates a merge commit. If there are any
merge conflicts
you'll be notified at this stage and you must resolve
the merge commits before proceeding
. When you are ready to push your
local commits, including your new merge commit, to the remote server,
run git push.

如若梦似彩虹 2025-01-25 23:47:26

场景:

  • 我从master说branch-1创建了一个分支并将其拉到我的本地。
  • 我的朋友从master 说branch-2 创建了一个分支。
  • 他向 master 提交了一些代码更改。
  • 现在我想将这些更改从主分支转移到我的本地分支。

解决方案

git stash // to save all existing changes in local branch
git checkout master // Switch to master branch from branch-1
git pull // take changes from the master
git checkout branch-1 // switchback to your own branch
git rebase master // merge all the changes and move you git head  forward
git stash apply // reapply all you saved changes 

执行“git stash apply”后,您会发现文件存在冲突。您需要手动修复它,现在您可以推送了。

Scenario :

  • I created a branch from master say branch-1 and pulled it to my local.
  • My Friend created a branch from master say branch-2.
  • He committed some code changes to master.
  • Now I want to take those changes from master branch to my local branch.

Solution

git stash // to save all existing changes in local branch
git checkout master // Switch to master branch from branch-1
git pull // take changes from the master
git checkout branch-1 // switchback to your own branch
git rebase master // merge all the changes and move you git head  forward
git stash apply // reapply all you saved changes 

You can find conflicts on your file after executing "git stash apply". You need to fix it manually and now you are ready to push.

看透却不说透 2025-01-25 23:47:26

将其与aq 合并

git checkout master
git pull
git checkout aq
git merge --no-ff master
git push

Merge it with aq

git checkout master
git pull
git checkout aq
git merge --no-ff master
git push
老街孤人 2025-01-25 23:47:26

Cherry-Pick相关提交aq或合并分支master中的分支中 aq 。

Either cherry-pick the relevant commits into branch aq or merge branch master into branch aq.

久而酒知 2025-01-25 23:47:26

简单的方法

# 1. Create a new remote branch A base on last master
# 2. Checkout A
# 3. Merge aq to A

Easy way

# 1. Create a new remote branch A base on last master
# 2. Checkout A
# 3. Merge aq to A
妳是的陽光 2025-01-25 23:47:26

对我来说,我已经进行了更改,我想要基本分支的最新信息。我无法做rebase樱桃 - 派克将永远使用,所以我做了以下操作:

git fetch origin <base branch name>  
git merge FETCH_HEAD

因此,在这种情况下:

git fetch origin master  
git merge FETCH_HEAD

For me, I had changes already in place and I wanted the latest from the base branch. I was unable to do rebase, and cherry-pick would have taken forever, so I did the following:

git fetch origin <base branch name>  
git merge FETCH_HEAD

so in this case:

git fetch origin master  
git merge FETCH_HEAD
冷弦 2025-01-25 23:47:26

编辑:

下面我的回答记录了一种将 master 合并到 aq 的方法,如果您查看合并的详细信息,它会列出所做的更改合并之前的 aq,而不是在 master 上进行的更改。我意识到这可能不是您想要的,即使您认为是这样!

就:

git checkout aq
git merge master

还好。

是的,这个简单的合并将显示当时从 masteraq 的更改,而不是相反;但这没关系——因为这就是发生的事情!稍后,当您最终将分支合并到 master 时,合并将最终显示对 master 所做的所有更改(这正是您想要的,并且是人们期望找到该信息的提交)。

我已经检查过了,下面的方法也显示了完全相同的更改(自 aqaq 之间原始分割以来对 aq 所做的所有更改当您最终将所有内容合并回 master 时,代码>master)就像上面的正常方法一样。所以我认为它唯一真正的缺点(除了过于复杂和非标准...... :-/ )是,如果你使用 git reset --hard HEAD~< 回退最近的更改/code> 并且这会超过合并,然后下面的版本会回滚到“错误”分支,您必须手动修复该分支(例如使用 git refloggit reset - 难的[sha])。


[所以,我之前的想法是:]

有一个问题:

git checkout aq
git merge master

因为合并提交中显示的更改(例如,如果您现在或稍后在 Github、Bitbucket 或您最喜欢的本地 git 历史查看器中查看)是在大师,这很可能不是你想要的。

另一方面

git checkout master
git merge aq

显示了 aq 中所做的更改,这可能就是您想要的。 (或者,至少,这通常是我想要的!)但是显示正确更改的合并位于错误的分支上!

怎么应对?!

完整的过程以合并提交结束,显示对 aq 所做的更改(按照上面的第二次合并),但合并影响 aq 分支,如下

git checkout master
git merge aq
git checkout aq
git merge master
git checkout master
git reset --hard HEAD~1
git checkout aq

:将 aq 合并到 master,将相同的合并快进到 master aq,在 master 上撤消它,然后让你再次回到 aq!

我觉得我错过了一些东西——这似乎是你显然想要的东西,而且是很难做到的东西。

另外,rebase 并不等同。它丢失了 aq 上提交的时间戳和身份,这也不是我想要的。

EDIT:

My answer below documents a way to merge master into aq, where if you view the details of the merge it lists the changes made on aq prior to the merge, not the changes made on master. I've realised that that probably isn't what you want, even if you think it is!

Just:

git checkout aq
git merge master

is fine.

Yes, this simple merge will show that the changes from master were made to aq at that point, not the other way round; but that is okay – since that is what did happen! Later on, when you finally merge your branch into master, that is when a merge will finally show all your changes as made to master (which is exactly what you want, and is the commit where people are going to expect to find that info anyway).

I've checked and the approach below also shows exactly the same changes (all the changes made on aq since the original split between aq and master) as the normal approach above, when you finally merge everything back to master. So I think its only real disadvantage (apart from being over-complex and non-standard... :-/ ) is that if you wind back n recent changes with git reset --hard HEAD~<n> and this goes past the merge, then the version below rolls back down the 'wrong' branch, which you have to fix up by hand (e.g. with git reflog & git reset --hard [sha]).


[So, what I previously thought was that:]

There is a problem with:

git checkout aq
git merge master

because the changes shown in the merge commit (e.g. if you look now or later in Github, Bitbucket or your favourite local git history viewer) are the changes made on master, which may well not be what you want.

On the other hand

git checkout master
git merge aq

shows the changes made in aq, which probably is what you want. (Or, at least, it's often what I want!) But the merge showing the right changes is on the wrong branch!

How to cope?!

The full process, ending up with a merge commit showing the changes made on aq (as per the second merge above), but with the merge affecting the aq branch, is:

git checkout master
git merge aq
git checkout aq
git merge master
git checkout master
git reset --hard HEAD~1
git checkout aq

This: merges aq onto master, fast-forwards that same merge onto aq, undoes it on master, and puts you back on aq again!

I feel like I'm missing something - this seems to be something you'd obviously want, and something that's hard to do.

Also, rebase is NOT equivalent. It loses the timestamps and identity of the commits made on aq, which is also not what I want.

贱贱哒 2025-01-25 23:47:26

您有几个选择。 git rebase master aq在分支上,该分支将保留提交名称,但如果这是远程分支,则不要重新列出。如果您不在乎保留提交名称,则可以GIT合并主AQ。如果您想保留提交名称,并且它是远程分支git cherry-pick&lt; commit ashh&gt;将提交在您的分支上。

You have a couple options. git rebase master aqonto the branch which will keep the commit names, but DO NOT REBASE if this is a remote branch. You can git merge master aq if you don't care about keeping the commit names. If you want to keep the commit names and it is a remote branch git cherry-pick <commit hash> the commits onto your branch.

李白 2025-01-25 23:47:26

只是为了区分 git merge 和 git rebase :

场景:

  • 您创建了一个功能分支
  • ,您对其进行了一些提交,
  • 您(或其他人)对 main 进行了更改
  • 你希望 main 中的更改反映在功能分支中

切换到功能分支 (git checkout your-feature-branch),然后:

  • git 合并通过创建一个具有两个父提交的新提交来集成两个分支:一个来自 main 分支,一个来自功能分支。

  • git rebase 本质上会移动或“重播”您的功能分支的提交,以便它们出现在 main 上的最新提交之后。 p>

Just to distinguish between git merge and git rebase:

Scenario:

  • you made a feature branch
  • you made some commits to it
  • you (or someone else) made changes to main
  • you want the changes in main to be reflected in the feature branch

Switch to the feature branch (git checkout your-feature-branch), then:

  • git merge integrates the two branches by creating a new commit that has two parent commits: one from the main branch and one from the feature branch.

  • git rebase will essentially move or "replay" your feature branch's commits so that they appear after the latest commit on main.

想挽留 2025-01-25 23:47:26

您也可以通过运行一行来做到这一点。
git合并aq master

这等同于

git checkout aq
git merge master

You can also do this by running a single line.
git merge aq master

This is equivalent to

git checkout aq
git merge master
宫墨修音 2025-01-25 23:47:26
1.git stash - apply this when you have uncommitted changes
2.git checkout master 
3.git pull 
4.git checkout branch1 (branch1 - Your working branch)
5.git rebase master 
6.git stash apply - apply whether you stashed uncommitted changes

应用藏匿处,您可能会发现合并冲突。手动解决它

1.git stash - apply this when you have uncommitted changes
2.git checkout master 
3.git pull 
4.git checkout branch1 (branch1 - Your working branch)
5.git rebase master 
6.git stash apply - apply whether you stashed uncommitted changes

You might find merging conflicts after applying stashes. Solve it manually

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文