Skip to content

Latest commit

 

History

History
66 lines (44 loc) · 3.73 KB

5. git rebase, cherry-pick and tags.md

File metadata and controls

66 lines (44 loc) · 3.73 KB
Raw

git rebase

What is rebase ?

Rebasing is changing the base of your branch from one commit to another making it appear as if you'd created your branch from a different commit.

It is used when we want to merge the master with feature branch but while developing the feature branch we have new commits in the master branch. Then we:

  1. simply rebase the base of the feature to the latest commit in the master branch. (also means rebase master into feature )
  2. then merge the master with the feature. This move the head of the master to the latest commit in the feature.
  3. Important thing to note is that when rebase of the feature branch is done, it creates a new copy of the feature branches.

Syntax: (HEAD is at feature branch):

git rebase master

Rebase creates new commits

Internally, Git accomplishes this by creating new commits and applying them to the specified base. It's very important to understand that even though the branch looks the same, it's composed of entirely new commits.

Points to remember:

  1. rebase means shifting of the base of a branch to another base
  2. This creates a new commit meaning that the history is rewritten. The commit ids will be different now.
  3. When commit ids are changed then it is ok when we are working in our local repository. But when working publically, the commit ids are changed and this could be difficult for other collaborators to access any previous commit.

When to use to use git rebase:

  1. When we have new commits while working in the feature branch
  2. when the feature relies on the additional commits in the master branch
  3. When the feature branch is finished developing and we want to implement it into master without merge commit:
    • rebase master into feature (this wouldn't effec the master branch but will change the ids of the feature branch commits)
    • then merge the feature into master

git cherry-pick

git cherry-pick is a powerful command that enables arbitrary Git commits to be picked by reference and appended to the current working HEAD. Cherry picking is the act of picking a commit from a branch and applying it to another

Scenario explaining cherry-pick

As shown above, suppose we want the changes in the master branch that made in the feature branch. The commit id is "L". Then we can move the head to the master branch and type:

git cherry-pick "L"

inplace of L it will be a commit id in real case but this is for example.

After this git will make a new commit on the master branch and incorporate the changes. Keep in mind that cherry-pick will always create a new commit.

For more information on cherry-pick

git tags

Git has the ability to tag specific points in a repository’s history as being important. Typically, people use this functionality to mark release points (v1.0, v2.0 and so on)

we can tag certain commits in our repository so that we can directly refer to the version if required in the future. The tags are mostly useful for highlighting the important milestones in our project for example version 1.0, version 2.0 etc

There are two different types of tags:

  1. lightweighted: A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit
  2. Annotated : Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, email, and date; have a tagging message;

The difference between the them is that one provides you with a tag message while the other doesn't