The original address

git reabase
git rebase
git merge

Git reabase and Git merge solve the same problem. Both commands are designed to merge changes on one branch into another — just in different ways. First think about what happens when you add new features to a working branch, and then another team member updates the Master branch by committing commitg. This produces a fork history, which should be familiar to anyone using Git as a collaboration tool.

merging
rebasing
marster 

git checkout feature
git merge master
Copy the code

Or I could write it as a line

git merge master feature
Copy the code

This will create a Merge commit on your working branch to link the histories of the two branches, as shown in the following figure: [IMAGE] (quiver – IMAGE – url / 3464 b87c2b36c0c3b8a72c5b623355c6. JPG = 561 x366) merge quite perfect because he is harmless, existing branch without any change, This avoids all of the reps pitfall (discussed below) on the other hand, it also means that every time an upstream change needs to be consolidated, the work branch will have an unrelated merge commit. If the Master branch changes too often, it can make your work branch’s commit record look ugly. Although using the advanced Git log option can alleviate this problem, it can be difficult for other developers to understand the history of the project.

As an alternative to merging, you can rebind the working branch to the Master branch using the following command:

git checkout feature
git rebase master
Copy the code

This moves the entire work branch ahead of the Master branch, effectively merging all new commits into the master. However, in contrast to using merge, the rebase operation rewrites the project history by creating a brand new commit for each commit in the original branch.

git merge
git log
git bisect
gitk

Interactive rebasing gives you the opportunity to change a commit as it is committed to a new branch. This is more powerful than automatic rebasing because it provides complete control over the commit history of the branch, usually cleaning up messy historical commits before merging into the trunk branch. To start an interactive rebinding session, add the I option to the git rebase command

git checkout feature
git rebase -i master
Copy the code

This will open a text editor listing all submissions that are about to be moved:

pick 33d5b7a Message for commit # 1
pick 9480b3d Message for commit # 2
pick 5c67e61 Message for commit # 3
Copy the code

This list clearly shows what the branch will look like after rebase is performed. By changing the pick command or reordering the items, you can make the commit history look the way you want it to. For example, if the second commit fixes a problem introduced in the first commit, you can use the fixup command to compress them into a single commit.

pick 33d5b7a Message for commit # 1
fixup 9480b3d Message for commit # 2
pick 5c67e61 Message for commit # 3
Copy the code

When you close or save the file, Git will perform rebase as instructed, and the commit history will look like this:

Rule number one: Never use it on a common branch

git rebase
git revert
push
--force 

# Be very careful with this command!
git push --force
Copy the code

This operation will override the remote master branch based on the master branch of the local repository, causing confusion to other members of the project. So you have to think twice before you do this. The only time you should force a push is if you perform a local cleanup (for backup purposes, for example) after you push a proprietary feature branch to a remote repository, which is like saying, “Oops, I don’t really want to push this original feature branch out. I’m going to replace it with something later. Equally important, no one commits code on the original branch. In this section, we’ll look at the advantages that rebasing can offer at various stages of feature development. The first step in any workflow that leverishes Git Rebase is to create a dedicated branch for each function. This will give you the necessary branching structure to safely utilize reps:

git checkout feature
git rebase -i HEAD~3
Copy the code

By specifying HEAD ~ 3 as the new base, you’re not actually moving the branch – you’re just interactively overwriting the three commits that follow it. Note that this does not merge the upstream changes into the functional branch.

git merge-base 

git merge-base feature master
Copy the code

This use of interactive rebinding is a good way to introduce Git rebase into the workflow, as it only affects local Branches. The only thing other developers will see is your finished product, which should have a clean, easy to follow feature branching history. However, this can only be used for private function branches. If you work with other developers through the same functional branch, which is public, then you are not allowed to rewrite its history. There is no alternative to Git Merge to clean up locally committed interactive Rebases.

In the overview section, we saw how a functional branch can merge upstream changes from the master using Git merge or Git rebase. Merge is a safe option that preserves the entire history of the repository, while rebasing creates a linear history by moving the feature branch to the Master branch. This use of Git rebase is similar to a local cleanup (it can be performed simultaneously), but it includes upstream commits from the master in the process. Keep in mind that it is perfectly legal to assign it to the remote branch rather than the Master branch. This can happen when you collaborate with other developers on the same function and need to merge their changes into the repository. For example, if you and another developer named John add commits to the function branch, your repository might look like this after fetching the remote function branch from John’s remote repository:

git pull
--rebase
rebase
pull
pull
git rebase
git merge
git rebase
git merge 

git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [Clean up the history]
git checkout master
git merge temporary-branch
Copy the code

### Summary That’s all you really need to know to start redistributing your branches. If you prefer a clean, linear history with no unnecessary merge commits, you should go to Git rebase instead of Git Merge to integrate changes from another branch. On the other hand, if you want to preserve the complete history of your project and avoid the risk of overwriting public commits, you can stick with Git Merge. Both options are fully valid, but at least for now you can choose to take advantage of git Rebase’s benefits.