10 of the egit user manual for git plug-ins on eeclipse _ simple parsing of rebase and merge

In this summary, why is it a simple analysis? Because rebase and merge have a heated discussion on the selection issue, I have no final conclusion, and git is also in the research and development stage, many theories are not completely mature yet.

If a multi-person development team submits updates frequently, the use of merge will make the historical line chart very complex, and merge will add a new record point at a time. If rebase is used, it is completely linear development.

The two results of merge and rebase are shown. Obviously, you don't want the chaotic results of merge. Can you tell me that the line in the merge diagram is a master branch?

Therefore, the following suggestions are provided. If the same file is repeatedly modified or submitted for a large number of times and many conflict statements are expected, you can use merge to merge the statements. You only need to resolve one conflict (however, should a new branch be created in advance for a wide range of thematic modifications ?); If the modification range is small and less conflict is expected, rebase is recommended.

In egit, the default pull operation is fetch + merge. If rebase is used, separate operations can be performed. Execute fetch to update remote tracking, and then execute rebase to merge (the rebase operation will be introduced in the next section ). Or modify the default pull Operation and configure it in the. Git/config file:

The preceding configuration is only valid for the mirror branch, and can be globally configured at $ home /. in gitconfig, if the Home variable is not configured in Windows, it is in the $ Documents and Settings/user directory by default: