I'm thinking of transforming my merge only workflow to using rebase more often. In this particular case, I'm the only developer, but I work on multiple platforms, often editing same files for platform-specific parts, usually with non-conflicting changes. But I'm a bit unsure about this, because of the debate about git merge vs git rebase, and their safety (for example see this vs. this, the two top answers of a question).
Question: how to do something like following, with goal of "safe" but still as clean as possible pull/rebase/merge:
git pull --rebase
until the first merge operation which conflicts with local history.git pull --no-rebase
to merge the rest and do conflict resolution.So if there are no conflicts, end result would be pull with rebase and nice linear history. If there are conflicts, then merges will be visible, but parallel history will be as short as possible.
Is this possible with a simple plain git command or two, with right switches (which I could write into a pull script or alias)? If not, is it possible with some existing tool?
Another way to look at this question: I want to automate the decision of choosing rebase or merge, so I don't need to think about that detail when doing pull.
Also, does this even make any sense? :)
I follow what you are suggesting. First I attempt a rebase, and if there is no conflicts then it just works, and your history is a lot cleaner. If there is a conflict I do a merge.
The only difference is I wouldn't attempt to split up the merge and rebase between commits of one pull as you are suggesting in your third bullet point. In fact, I'm not sure that even makes sense. It seems the same as working through conflicts and doing rebase continue
when you resolve the conflicts. The result would be the same as a rebase with conflicts.
If you have changes that need to be pushed. Either do a rebase or, if there is conflicts, do a merge.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With