|
|
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. So you want to do:
|
|
|
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?
|
|
|
|
|
|
git merge master
|
|
|
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 is this a good idea? Ralf proposes to use git rebase.
|
|
|
But here is a summary and guildelines how to work in CORSIKA.
|
|
|
|
|
|
The web is not so clear about what is the best method, in fact both methods are frequently recommended.
|
|
|
This is one blog entry explaining some issues around the options:
|
|
|
The difference between merge and rebase is illustrated here:
|
|
|
|
|
|
https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1
|
|
|
![image](uploads/0a330dc12d8a281abf21464626d2c2df/image.png)
|
|
|
|
|
|
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 master` since 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`, or `fast-forward merge` if suggested by gitlab. This is the best way to retain a good development history, and will allow to trace bugs and changes.
|
|
|
|
|
|
This wiki page is meant to develop into some recommendations when using git. |