CODEWITHSUNDEEP
gitversion-controlbitbucketatlassian-sourcetree
Cur Fromsky
Cur Fromsky

Reputation: 25

How do you explain the commit/graphs of this Sourcetree repo I just cloned?

enter image description here

I have a few questions with sourcetree and git in general. Does sourcetree show the commits of everybody that cloned the project? If my friend clones a remote repo and then does several commits on his end, would my sourcetree know about those changes and display them for me? How would my sourcetree know about my friend's local commits if he doesn't push them? Would my sourcetree and my friend's sourcetree look exactly the same at all times?

As for this picture, I cloned a remote repo and didn't touch anything. Can you explain precisely what happened at each stage? I don't understand why there are 2 initial commits and why it looks like they are merging at the last step, they aren't branches right? Do the colors have any significance? Thank you.

Upvotes: -1

Views: 87

Answers (1)

matt
matt

Reputation: 535890

First, it is important to understand that there is nothing wrong; everything here is perfectly normal.

Having said that, I will propose a simple and common scenario that would result in what you are seeing.

Alice starts a Git repo on her machine:

cd someDir
git init
git add .
git commit -m 'initial commit'

Alice wants to share this repo with Bob. To do so, Alice wants to push the repo to a common server. Let us say it is GitHub (or it might be BitBucket, it doesn't matter). Alice cannot push to a remote repo immediately; it is necessarily first to go, in some other way, to the remote site and create the remote repo.

So, using a web browser, Alice goes to GitHub (or BitBucket) and asks to create a new repo. Call it mycoolrepo. In the web browser interface, GitHub (or BitBucket) asks whether Alice wants to include some basic common material, such as a README file and a .gitignore file, in this new repo. Alice says yes. So GitHub (or BitBucket) creates the repo, making a new master branch consisting of a commit whose commit message is "initial commit".

Back on the local repo, Alice configures the remote repo as the remote for the local repo:

git remote add origin https://github.com/alice/mycoolrepo.git

Now Alice tries to push from the local to the remote:

git push origin master

Git refuses to allow this! It puts up a fatal result, with a hint explaining what the problem is, and what to do about it. Git says, in effect: "You cannot push to a remote that has commits you don't have in your local. [Recall that this is indeed true: there is an initial commit created on the remote end that is different from the initial commit on Alice's local.] To fix this, you have pull before you can push."

So Alice does that!

git pull origin master

Well, now there's a new problem: Git refuses to pull! The new error says: fatal: refusing to merge unrelated histories. Well, nothing daunted, Alice tries again:

git pull --allow-unrelated-histories origin master

Success at last! The result is that, by default, Git pulls down the initial commit from the remote and creates a merge commit on master. Alice now has this:

A [initial commit by Alice] - M (merge commit; master)
                           /
                          /
 B [remote initial commit]

Now Alice tries again to push:

git push origin master

Success! Now Alice tells Bob, okay, go ahead and clone the repo at https://github.com/alice/mycoolrepo.git, it's ready for you.

Bob does clone that repo, and gets an exact copy of it. Therefore Bob now has:

A [initial commit by Alice] - M (merge commit; master)
                           /
                          /
 B [remote initial commit]

Bob = you, and that diagram, turned on its side, = your diagram.

Upvotes: 1

Related Questions