如何从分支 B 合并到 A 时从分支 A 获取最新提交？

Question

I need to checkout a version of my project locally so I can work on features that existed before branch B was merged into A, so I need to work with latest commit from A just before B was merged.

Thanks in advance.

Edit

Suppose we have commit 1 on the branch A and on branch B we have commit 2,3,4,5...n. As the branch wasn't merged until som time later, some other pr were merged into A, so we have now on A commits 1,n+1,...Y.

Now we will merge branch B into A and keep the work going until some months later.

First question is: Will A stays as 1,n+1,...Y,2,3,4,5...n after the merge?

Main question: How can I get commit 1 if I don't now it's id or commit message?

Answer 1

You can do a git pull to make sure your project is up-to-date with the repository. Now grab the commit id from before B was merged (we'll call it commit-id) and execute following commands:

$git branch my-new-branch                //This will create a new branch
$git branch -f my-new-branch commit-id   //This will point your local branch to the new commit

Answer 2

Use cherry pick to bring changes in to current branch from another branch

Answer 3

You can check out any historical commit, as a detached HEAD . This uses a special mode in Git, one where you view a commit but normally don't actually do any new work.

To do this, find the commit's raw hash ID, or use any Git tag , which is mostly a way of putting a human-readable name in to say this name shall, from now until the true death of this project, mean hash ID _____ (fill in the blank). Use this hash ID or human-readable name as an argument to git checkout or git switch . If you're using a raw hash ID, you can abbreviate as long as it is not ambiguous, but the easy way to get it right—raw hash IDs are very unfriendly to humans, who always ¹ get them wrong—is to cut-and-paste the hash ID from some git log output for instance:

git checkout 86ab15cb154862b6fa5cc646dac27532f881e1fb

When you are working with a Git repository, you normally work with one where Git has prepared a working tree or work-tree area for you. This git checkout fills in your work-tree from the commit you specify, which becomes the current commit.

(If you have Git 2.23 or later, you may wish to use git switch instead of git checkout here. It does exactly the same thing, for this case.)

---

¹ Insert distorted Gilbert-&-Sullivan routine here. "What, never? No, always." or something like that.

---

What detached HEAD vs non-detached (attached) HEAD mode is all about

In normal everyday Git usage, you use something like:

git checkout master        # or git switch master

or:

git checkout develop       # or git switch develop

where you supply a branch name . The branch name selects a commit (by its hash ID as always) and Git fills in your work-tree from that commit, but instead of just picking a commit, this also tells Git: ... and when I make my next commit, add it to the branch I am using.

When you use:

git checkout <raw hash ID>

you're still selecting a commit, but promising Git that if you do make later commits, they're all temporary and can all be thrown away later. So you can use the work-tree files all you like, for viewing or compiling or whatever, but you don't normally actually make any new commits.

(If you do make new commits in this mode, you get an opportunity to tell Git oh, and keep these around now , as long as you do it reasonably quickly—within a month or so, by default—of re-attaching HEAD to a branch, or switching to another commit. Git also uses this detached HEAD mode internally for some of its own operations, such as doing git rebase .)