如何在我在 git 中选择的分支中找到我需要的文件？

Question

In git, I want to find files, I want to choose a branch. for example, look at below.

git diff --name-status comitaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx..comitbxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
M    fileA.txt   // it was changed in xxx branch.
M    fileB.txt   // it was changed in yyy branch.
M    fileC.txt   // it was changed in zzz branch.

if I wanted to find fileB.txt, how can I use the git command?

Answer 1

Files aren't changed in branches , in Git. In fact, files aren't even stored in branches. Files are stored in commits .

You might wonder what good branches are, in Git. You probably should wonder, because branches aren't really much good at all in Git—though this depends on how, exactly, you define branch , because the word branch itself is ambiguous, in Git. There's a better-defined term, branch name , that you might want to use instead. What branch names do, in Git, is allow you—and Git—to find commits. The reason for this is that the true name of a commit is a big, ugly, random-looking number, expressed in hexadecimal , impossible for humans to remember or deal with.

 git diff --name-status xxx..yyy

Note: this means the same thing as:

git diff --name-status xxx yyy

The xxx and yyy here are commit hash IDs , or something that resolves to a commit hash ID , such as a branch name. Git needs these so that it can find the two specific commits.

Git then extracts both commits . Each commit holds a full snapshot of every file , so this produces two different snapshots. Git then compares the two snapshots:

• If some file is in both snapshots, and is the same in both snapshots, Git says nothing at all about that file.
• If some file exists in only one of the two snapshots, Git will—usually ¹ —tell you that the file was created (exists in yyy , missing in xxx ) or deleted (exists in xxx , missing in yyy ).
• If the file exists in both snapshots, Git will (again, usually) tell you that the file was modified, and show you some set of changes that, if applied to the left-side ( xxx ) copy, will produce the right-side ( yyy ) copy.

---

¹ I say usually because there are a lot of corner cases, including, eg, --name-only , where the status is dropped, or rename detection , where a file that went missing on the left is matched up with a newly created file on the right, as a rename operation.

---

 M fileA.txt // it was changed in xxx branch. M fileB.txt // it was changed in yyy branch. M fileC.txt // it was changed in zzz branch.

The comments here imagine something that is simply not findable: M just means that these three files exist in both left and right side commits, but have different contents.

Any one commit can exist in multiple different branches. Each commit holds a full snapshot of every file, so no file is ever changed in a commit. Files are changed between two commits , or aren't changed between those two commits.

At the same time, though, each commit also holds information saying which particular commit hash ID(s) are the immediate predecessor of that commit. So if we have a string of commits, all in a row, like this:

... <-F <-G <-H

we can have Git start at commit H and work backwards:

• First, we have Git use commit H to locate commit G , and compare the two snapshots. For whatever files are different in these two commits , we claim that these files are changed in commit H . This is just a way of looking at things—commit H is purely a snapshot, not changes, but by comparing it to an earlier snapshot, we can see it as changes.

• Then, we have Git use commit H to locate commit G again, but this time we now consider commit G on its own. It has an earlier commit F recorded, so we have Git use G to locate F and compare the two snapshots . Whatever is different, we claim is "changed in G ", as before.

• Of course, G 's parent commit F is an ordinary commit as well, with some earlier commit (presumably E ). We repeat this process, over and over again.

If these three commits are only found by starting at branch name feature , people claim that the files were "changed in branch feature ":

A--B--C   <-- main
       \
        D--E--F--G--H   <-- feature

But here's the weird thing about Git branch names: we can create and destroy them at any time . Let's create a name, zorg , right now and make it point to commit G :

A--B--C   <-- main
       \
        D--E--F--G   <-- zorg
                  \
                   H   <-- feature

The set of commits in this repository is unchanged. All commits are frozen for all time: no part of any commit can ever change. So the changes between commits F and G , which we said were feature -branch changes a moment ago ... well, they're still there, between F and G , but now they're zorg -branch changes.

What this means is that unless you hold the branch names fixed too (which Git doesn't, on purpose), you can't say that some change is due to some branch . It's merely due to some set of commits . Don't ask about branches; ask about commits .