git safe rebase or “try rebase, fallback to merge”

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:

  • How to do git-svn fetch and retain empty directory?
  • Git Bash: Launch Application via Alias without hanging Bash (WIndows)
  • How to ensure that Visual Studio Online Git Repository is private?
  • git commit searches source and extracts comments
  • Is it possible to get a working tree in a bare git repo?
  • Git squash history after merge
    • If there are un-pushed commits, then git pull --rebase until the first merge operation which conflicts with local history.
    • Then git pull --no-rebase to merge the rest and do conflict resolution.
    • Possibly switch back to rebasing for last non-conflicting changes, to keep the parallel part of history as short as possible.

    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? 🙂

  • SVN merge just a directory add from a checkin (without directory contents)
  • git SHA1 0000000000000000000000000000000000000000 (all zeroes), is this normal?
  • git.Run() had no output
  • How to custmoize git.el's diff face in Emacs?
  • Error at git checkout. Path too long
  • Ignore all dir's but one
  • One Solution collect form web for “git safe rebase or “try rebase, fallback to merge””

    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.

    Git Baby is a git and github fan, let's start git clone.