Making sense of Git and GitHub - V [Rebase , GitHub ]

Are you tired of merging and resolving conflict?

We are okay with 'fast-forward merge' as it is not creating an auto-generated merge commit.

When you observe the difference between fast-forward and three-way merge, it all depends on the base commit.


What is base commit?

Base commit is the commit from which the branch originated.

Here, the base commit for Branch1 is the one on the master that contains File1.txt and File2.txt.

When you do branching, you have non-linear commit history.
So what is non-linear commit history?

Do the setup as usual in it, like the above illustration.

Merge it. Here there will be no conflict. If you want conflict, make changes in the same file on both branches. Then resolve the conflict and merge it.


Anyway, after merging,

Type git log --oneline --graph --> This will give you the commit history in graph format.

From the image above,

We can infer that ded118b(Second commit from master) is the base commit because Branch1 is created from that commit.


If you see the commit history,

Note:[Each * is the commit]


We don't have one straight path(linear history) but two different paths(non-linear) in the commit history.


To make commit history linear, we need to rebase in git and merge.

Rebase = Changing the base commit to the latest commit in the master branch.

Hands-on: Git rebase

Do the setup in git as same as the above illustration.

Remember that a new commit is created while changing the base commit. Hence commit-id before and after rebase are different.


We will prove everything above.

We will create a branch from the second commit(base commit). Then rebase it.

Before rebasing the commit history and please note that the commit id.

Master branch commit history:

Branch1 commit history:


Which branch is changing the base? Branch1.

So it is obvious to execute rebase from Branch1.

What is the command? git rebase master.

Type git rebase master and then git log --oneline,

Note: The third commit is inserted, and on top of it, Branch1 commits are inserted with new commit ids. This is called rebasing.

Since the commit id is changing and the base commit is changing, we can't track all the commit history if many developers collaborate on a particular project. It is not advisable to rebase if the remote repository and more collaborators are there.


But we can use it in our local repo, as we fully control it!


Also, our original commit is duplicated with a new id.


What about commit history in master?


It doesn't reflect in the master branch, so we need to merge because we have only done rebasing.


From where do we need to merge? master branch!

Go to master and type git merge Branch1,

Give git commit --oneline now,

Yes, we merged.

That's the whole idea of rebasing in git.


GitHub:

We know Git is the local repository, and GitHub is a remote repository. By remote, I mean some server sitting somewhere in the world and storing our repository.


We can pull and push code in GitHub.

Before that, we need to create a repository in GitHub.You can open an account in GitHub using the mail id, and basic instructions are available on their website.


After opening an account, we need to create a repository by clicking a new button on the website.


You need to give the repository name and description of this repo.

You can either set it public or private.


After creating a repo, you can clone or pull. After you create a repository, you can push your code there.

As GitHub provides cloud services, we can collaborate with many developers on the same repo.

If anybody wants to take the code, they need to clone the repo.

Give git clone <url>,

You can find the URL here in the repo,


git clone https://github.com/pansofarjun/github.git

Then you can start coding and use git.

If you want to send or receive a code from now on,

You need to pull or push in and out of the GitHub repo.


Now you have cloned the code, and it becomes a git repository on your local machine. But every time you push or pull in GitHub, you need to remember the URL of the repo.

Git has a way around this: it remembers the URL and assigns it as 'origin.'


So,


git push origin master --> Sends the code
git pull origin master --> Takes the code
Pull = Clone + Merging with your code. It is essential for teamwork.