Let's say you have a feature branch, and you worked on it for quite a while. In the meantime the master went on, so your branch is not in sync with the HEAD. To test your changes with the latest version you want to pull the current status into your feature branch. What to do?
The discussion is complex and you can see more details e.g. https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 or https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd77c
But here is a summary and guildelines how to work in CORSIKA.
The difference between merge and rebase is illustrated here:
While rebase will yield a flat and clean history, merge will be much more reflecting on the development work that was ongoing. In the end: BOTH ARE NEEDED, but for different purposes.
The main problem of rebase is, that the commits on the feature branch after the rebase are DIFFERENT from before. Rebasing REWRITES history. It is obvious that this can cause major problems, if several people work on one branch. If one of them rebases, it invalidates the history of each other checked-out branch.
Merging, on the other hand, always produces a merge commit. This makes a lot of sense, when merging a feature branch into master. But it can pollute history if a feature branch is developed for a long time and frequently git merge master is executed: there will be lot of superfluous extra merge commit on this feature branch.
Thus, a good compromise is the following:
-
try to avoid long-lived feature branches, and keep the scope of a feature branch as small as possible. This will avoid most conflicts.
-
if you work on your feature branch ALONE (or mostly alone) but you need to pull in recent changes from the master, you need to use
git rebase mastersince this will basically just put your feature branch on top of the most recent master branch. This is very useful for developing a new feature, or fix a bug. -
if other people have checkouts of your branch. Inform them about your rebase! Make sure they obtain the latest, rewritten commit history from you! It can be that you have to coordinate with others to make this happen.
-
if the latter is not possible or too complicate to coordinate, use
git merge master. When several people actively work together, or when some people do testing while other do developments, this is the best option. -
Finally, to close a feature branch and to merge it back into the master, we use
merge, orfast-forward mergeif suggested by gitlab. This is the best way to retain a good development history, and will allow to trace bugs and changes. -
During merging to master, squashing the history may be a good alternative in special cases. This should be determined during the "approval" process. Squashing will loose the detailed commit history, but sometimes in special cases this is exactly what is best...