git log contain commit for another branch, how to separate commit beween branch
How to separate changes between branch?
- I create new branch with name BRANCH-1, made a changes, and commit the changes
- I create new branch with name BRANCH-2, made a changes, and commit the changes.
- I create new branch with name BRANCH-3, made a changes, and commit the changes.
my problem is, BRANCH-2 contain commit & changes from BRANCH-1
and BRANCH-3 contain commit & changes from BRANCH-1 and BRANCH-2
how to separate the changes and commit on each branch?
Those commits are in fact on all of those branches.
Consider the following. We start with a single branch named
main. The name
main locates one specific commit, with one specific hash ID
H. (The real hash ID is some big ugly random-looking thing, hence the use of uppercase letters as stand-ins.)
H contains two things:
- a source snapshot—a full copy of every file as it appears in the latest commit; and
- some metadata that holds stuff like the name and email address of the person who made the commit.
The metadata in commit
H contains the hash ID of some earlier commit. We say that
H points to the earlier commit, and the name
main points to commit
The hash ID inside
H itself is that of some other commit, so let’s draw in that commit, which we’ll call
<-G <-H <--main
Of course, earlier commit
G points to some yet-earlier commit
... <-F <-G <-H <--main
and so on down the line. Eventually we run out of "earlier" commits because we hit the very first one. Getting slightly lazy about drawing the arrows, this gives us a more complete picture:
A--B--C--D--E--F--G--H <-- main (HEAD)
HEAD tells us that we did a
git checkout main.
Let’s now add one new branch name, such as
develop. Git requires that a branch name contain the hash ID of some valid, existing commit. Which of these commits should we use? The most obvious candidate is the current and latest commit,
A--B--C--D--E--F--G--H <-- develop, main (HEAD)
If we now check out
develop, the special name
HEAD, which remembers which branch name is the current branch, moves:
A--B--C--D--E--F--G--H <-- develop (HEAD), main
We are still using commit
H. We’re just using it through the name
Which branch(es) are the commits on? All commits are, pretty obviously, on both branches.
When we make a new commit, Git will:
- package up all of the source files as a new snapshot;
- add some metadata, with the right name and email address from
user.email(those can’t possibly be lies: they must be right!), "now" as the date-and-time, and so on.
Git will get the log message from us or from the
-m argument, and will use the current commit as the place that the new commit will point backwards to:
I / A--B--C--D--E--F--G--H <-- main
Because we are
on branch develop, as
git status will say, Git will store new commit
I‘s hash ID into the name to which
HEAD is attached,
develop, like this:
I <-- develop (HEAD) / A--B--C--D--E--F--G--H <-- main
Which commits are on branch
develop? All of them, just as before. It’s not the case that only commit
I is on
develop. All the commits are on
develop. It’s just that commits up through
H are also on
If we now
git checkout main, Git will:
- remove all the files that go with commit
- extract all the files that go with commit
The result is:
I <-- develop / A--B--C--D--E--F--G--H <-- main (HEAD)
Nothing has changed in the commits and branches in the repository, except for where
HEAD is attached; but our working tree (and Git’s index or staging area) are now updated to match commit
If we now create another new branch name
topic, and switch to it, we get:
I <-- develop / A--B--C--D--E--F--G--H <-- main, topic (HEAD)
If we now make another new commit, we get:
I <-- develop / A--B--C--D--E--F--G--H <-- main \ J <-- topic (HEAD)
This is what branches are all about, in Git: they’re ways to find commits.
It is the commits that are all important. Each commit stores a full snapshot of every file, in a special, read-only, Git-only, compressed and de-duplicated form. So if commits
J all share most of their files, they literally share the files, even though each one has its own full copy. (This sharing is enabled because the contents are read-only.)
To see what changed in any given commit, Git simply follows the commit’s internal backwards arrow to its parent. That parent has a snapshot too. Whatever files are the same in both commits are not changed, and since Git is doing de-duplication, it can find this out very fast. For files that are changed, Git compares their content to see what changed, and shows you a diff (this is computed on demand, not stored in the commit).
To make branches be "independent", just start them all far enough back. Here, branch
topic and branch
develop both started from commit
main. That means changes we made, and then used to make the snapshots
J, aren’t reflected in the other commit, which started with copies of files from
(Later, if and when we go to merge branches
H—the best shared commit, on both branches—will be very important.)
Answered By – torek