Git, view multiple branches in the same repository

Question

Here is our work process:

1. Developers are cloning from a central repository.
2. Dev A is locally working on bug fix A, branch bug_a, push branch bug_a to central repository.
3. Dev B is locally working on bug fix B, branch bug_b, push branch bug_b to central repository.
4. When the work is finished the branches are merged to a develop branch.

Lets assume (for simplicity) that both branches do not touch common files. Our requirement is that in the end exactly can be reconstructed which files and code is changed with bug_a. The same for bug_b. So the commit for the merge of bug_a in develop shows exact the changes done for this bug A solution.

Now the question arises: I am working on bug_a and I want to see the changes of bug_b in my repository.

I know I can pull the changes of bug_b in my bug_a branch BUT now my requirement is not fulfilled because at the final merge/commit in develop I see also the changes of bug_b and I cannot reconstruct the exact changes done for solving bug A.

My question is there a command or procedure in Git where the changes made in other branches are visible in the local working branch? Just like a 'view' in clearcase e.g.

master
develop
bug_b
*bug_a

Answer 1

To abuse some terminology, each git repo is itself a lot like a clearcase private view: you can't see the other guy's directly. (But there's a shortcut I will mention in a bit.)

Fortunately, you can see his indirectly, because you two have a third, shared repo. He pushes to the shared repo, then you fetch (don't pull yet because that complicates the answer) from the shared repo. Now you can see what he did, because fetch grabs (by default anyway) everything.

Here's where git is very different from clearcase, though: you "see what he did" by asking git to extract it to somewhere visible. It won't "just show up", you have to tell it "let me see".

You can see it by doing one or more of the following:

• asking git (or a GUI) to show diffs
• asking git to check out a different branch into the current work tree (there is obvious potential for collisions here)
• asking git to check out the contents of one or more particular files from a particular branch, into the current work tree
• asking git to check out a different branch into a different (perhaps new) work tree

All of these need some understanding of how to specify particular revisions (by "branch name" or by commit-ID or whatever). Here's two important things to keep in mind:

• When you clone and fetch, git creates branches with names like remotes/origin/master and remotes/origin/bug_b.
• When you work locally in your repo, git creates branches with names like master and bug_a.

So, to view changes that have been fetched into remotes/origin/bug_b, use:

git log remotes/origin/bug_b

Note that you need not have your own branch named bug_b, much less do any merge-ing or pull-ing or whatever. Just name the remote branch, when you only want to look. You only need your own branch name if you're going to do your own work on a bug_b branch.

Here's a deeper bit that you don't need to understand yet, but you should come back to it now and then: a branch name like remotes/origin/bug_b is really just a symbolic way to name one of those big git SHA1 values like ae0af6d748b98716f0f72e428728345b828c4067. What git does when you fetch is to obtain all the new files and trees and such, and all the commits with those big hairy IDs, and stuff all of them into your repository; then update the remotes/x/y labels to point to the "tips" of each "remote branch". Your repo has everything everyone has ever done, right there at your fingertips if needed. (Sometimes that turns out to "too much" so there are ways of limiting how much you actually have, but "everything" is the default, and is the way to think about it.) (In clearcase-ish terms, you have a complete copy of every VOB. Fortunately git is way more space- and time-efficient than clearcase.)

When you do a git pull you're really doing two things: a git fetch—this is what pulls changes over—and then (normally) a git merge. The merge combines "work someone else did" with "work you did". You don't want that when you're fetching the changes Bob did for bug_b while working on your own bug_a branch.

(Optionally, you can tell git to make git pull mean git fetch followed by git rebase. But you don't want that either. Just stick with git fetch.)

Now, for that shortcut: if you git clone the original shared repo, then you have to wait for Bob to git push his bug_b changes back to the shared repo, before you can see them. But, if Bob grants you read access (via ssh or whatever) to his private repo, you can add Bob's repo as an alternate "remote". Instead of remotes/origin/bug_b you can name this remote remotes/bob/ for instance, and refer to remotes/bob/bug_b. You can fetch those with git remote update bob. Don't bother with all this unless you can coordinate with Bob, though. The single shared repo to which you both push is usually the way to go.

Answer 2

Assume you have branch A checked out, and you want to view changes made in branch B. Then you can see the changes made in B with

git log --patch B

which will show you all the commits made in B, along with the diff of the changes that each commit introduces. You can read more about using git log at the Git docs.

If you don't have the latest changes made in B from your remote/central repo in your local repo, you can git fetch <remote repo> those changes into your local repo, without merging those changes into A. Then you can view those changes with

git log --patch remoteRepo/B

A lot of Git guis have visual diff viewers that you can use as well, to view any branch that you want.