Merge is a simple way to manage your code, with a very clear git log/history that tells you when changes from different branches were combined. Your changes are clearly differentiated from merge commits, which will even be helpfully greyed-out in most popular hosted git services. They can get pretty unwieldy if you let a branch live for a really long time, particularly if you aren't updating it regularly. So try to do short, contained branches and update them regularly. Keep a clean workflow - never work on master, always branch from master, use pull requests to merge back to master.

Rebase and its constant companion squash are for the thrill-seeking developer, who prefers a little uncertainty in their life. When were the changes merged? Who knows! The history will tell you the PR your coworker just raised was completed three days ago. Everyone loves a bit of mystery in their history! Maybe rebase will fail and require you to do a tricky set of actions to combine upstream changes, because a simple conflict resolution just isn't a hard enough problem - we like proving we're really smart by solving hard problems right? One wrong move and you've just reverted that critical fix your team mates worked so hard on. Go team! If you're really lucky, rebase will totally explode and you'll spend hours with a lovely puzzle to figure out - much better than getting that critical bugfix released. But in the end, rebase will avoid a few greyed-out commits... and all that effort will seem totally worthwhile.

Jokes aside a rebase workflow does work fine, I just prefer merge ;)

I am a visual person, and I always explain with graphics if possible. I would have added the following to the already great answer from Ipseeta Priyadarshini

before:

a---b---c (master)
     \
      d---e (dev)

after merge:

a---b---c---d (master) (dev)
     \     /
      d---e

d is called a merge commit

after rebase:

a---b---c---d2---e2 (master) (dev)

d and e have been rewritten on top of master and now have different names (hash).

Hey Sandeep Panda nice start to gather basic knowledge.

To answer this, let's take the example of master and development branch. To merge the content of master branch into development branch, we use

git merge development master

or

git checkout development
git merge master

Now, we have a new merge commit in development branch which doesn't alter the history of development branch.

To rebase a branch means moving the base of the branch to a different position, i.e; re-writing the project history by inserting brand new commits.

git checkout development
git rebase master

💡Use merge when you work on a shared branch and use rebase when you are the only one working on the branch. This is because altering the history of a shared branch might introduce conflicts.