Believe that most friends often encounter the problem of merging branches, as the Internet should have a lot of similar articles, this article will be simple and violence, from the perspective of the most commonly used the most practical to rebase and merge

preface

The first thing to understand is that Git Rebase and Git Merge solve the same problem. Both commands are designed to integrate changes from one branch to the other, they just do it differently.

Imagine what happens when you start developing new features in a dedicated branch and another team member updates the Master branch with a new commit. This produces a fork history that should be familiar to anyone who uses Git.

Now, let’s talk about when a new master commit is relevant to the feature you’re working on. To merge new commits into your feature branch, you have two options: Merge or rebase.

Merge

The easiest way is to merge the master branch into the feature branch:

git checkout feature

git merge master

Simplified to one line:

git merge master feature

This creates a new “Merge Commit” in the feature branch.

Merge is good because it is a non-destructive operation. The existing branch structure does not change in any way. This avoids all of Rebase’s potential pitfalls (described below).

On the other hand, this also means that the feature needs to be merged every time it changes upstream, and there are unrelated merge commits. If the master changes very frequently, your branch history will be very messy. Although this problem can be mitigated with the advanced Git log option, it can make it difficult for other developers to understand the project’s history of changes.

Rebase

As an alternative to merge, you can rebase the feature branch onto the master branch using the following command:

git checkout feature

git rebase master

This moves the entire feature branch to the top of the Master branch, effectively integrating all new master commits. However, instead of using a Merge COMMIT, Rebase overwrites the project history by creating a new commit for each commit in the original branch.

The main benefit of Rebase is a clearer project history. First, it eliminates unnecessary Merge commit from Git merge. Second, as you can see in the figure above, Rebase also produces a perfectly linear project history – you can follow from the top of the feature branch to the beginning of the project without any forks. This makes it easier to navigate projects than commands like Git log, Git bisect, and gitk.

However, there are two trade-offs for this original commit history: security and traceability. Rewriting project history can be disastrous for your collaborative workflow if you don’t follow some of Rebase’s rules. Second, rebase loses the context provided by the Merge Commit – you can’t see when the upstream changes are merged into the functionality.

Rebase’s Golden Rule

Git rebase’s golden rule is never to use it in a public branch.

For example, consider what would happen if you rebase the master branch to your feature branch:

Rebase moves all master commits to the top of the feature. The problem is that this only happens in your warehouse. All other developers are still using the original version of Master. Because rebase causes completely new commits, Git will assume that the history of your Master branch is different from the history of everyone else.

The only way to synchronize the two Master branches is to merge them together, resulting in additional merge commits and two sets of commits containing the same changes (the original commit and the changes from the Rebase branch). This would be a very confusing situation.

Therefore, before you run Git Rebase, always ask yourself, “Is anyone else using this branch?” If the answer is yes, take your hands off the keyboard and consider doing it in a non-destructive way (for example, git revert)

Rebase field

Two scenarios are used most frequently by Rebase:

  • Merge multiple COMMIT commits
  • Merge other branch code

1. Merge multiple COMMIT commits

Why merge multiple Commits? A: When you’re developing a feature, you’re going to have to tinker and tinker and make multiple commits, all for the same feature, so there’s no point in committing too many commits, it’s not going to make sense to look at a long list of commits

For example, we developed on the CESHI branch and produced three commits

At this point, I want to merge these three commits, and only represent one commit on the remote repository. How do I do this? Execute the following command to do this:

Git rebase -i [startPoint] [endpoint]  git rebase -i 0845a3584bdc2c6718dd4a2d663478848191ee6d 22d18e4fb994abbabb90fb3ba107332c1d5ecfacCopy the code

Git rebase -i [startpoint] [endpoint] -i [startPoint] refers to the starting point of the combined interval; [endpoint] refers to the end of the merge interval, which by default is the COMMIT that the current branch HEAD points to. Note: this interval is a commit_ID1, commit_ID2].

Press Enter to enter the next interface:

Enter I on the above interface to enter INSERT editing mode. Squash for modification. Press Esc to exit editing and enter :wq to save the modification and exit git log

Then the push branch is bound to fail, because at this point the cesHI branch has entered the temporary branch

Don’t panic, follow these steps:

Create dev-temp branch based on temporary branch with no name: git checkout -b ceshi1\

Git checkout ceshi\

Git rebase ceshi1

If there is a conflict, resolve it

All right, just do git push

You can also merge multiple commits to another branch and learn git rebase –onto on your own

2. Merge other branches

Git merge merge git rebase merge git rebase merge git rebase merge

Following that, while we were working on a feature in the CesHI branch, the rest of the team was also working on features 1 and 2 on the same project, which were submitted and merged into the Dev branch:

At this point, the ceshi branch is behind the current dev branch because the dev branch already has the latest 1 and 2 features

How do YOU merge dev branches that contain new commits? Git rebase dev in the current branch is simple

  1. rebaseInside theceshiIn the branchcommitCancel;
  2. To cancel thecommitStored in the.git/rebaseDirectory;
  3. theceshiBranch updates to the latestdevBranch (Just to give you a sense of what this means);
  4. The preservation ofcommitApplied to thedevBranch.

Git log (cesHI branch

However, code conflicts are more common. If you change the same file when developing A and B, for example, you changed the readme.md content when developing A, then you might have A conflict

  1. In the firstIDE(I useVSCode) Handle conflicts manually and save them;
  2. Execute after the conflict is handledgit add ., note: executegit add .This command does not need to be executedgit commit;
  3. Continue to performrebaseCommand:git rebase --continueIf there are still conflicts, repeat the above steps until the branch merge is complete, as shown below.
  4. Remember, inrebaseOnce the process is in a muddled state, you can terminate the current at any timerebaseOperation:git rebase --abortFigure it out and start again.

The end of the