git-rebase

I have a Git repository with a branch that hardly ever changes (nobody else is contributing to it). It is basically the master branch with some code and files stripped out. Having this branch around makes it easy for me to package up a leaner version of my project without having to strip out the code and files manually every time. I have been using git rebase to keep this branch up to date with the master but I always get this warning when I try to push the branch after rebasing: To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing

Based on this: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase git rebase will make it possible to maintain a linear history (a merge "always" results in a fast-forward) But if I want to enforce a linear history and require developers to always rebase their feature branches on latest master will that not result in collaboration/sharing feature branches going out the window? See: Don't rebase public history so is it possible to enforce linear history using git rebase and at the same time allow multiple developers to contribute to the same feature branch? Or will git rebase

Recently I had a lot of success rebasing a local-only repository while changing commit messages and after that only the commit messages had been changed but the history itself hasn't. Now I have my repositories - remotely and locally. I made several commits on several branches and already pushed them. Due some reasons I need to change some commit masseages over several branches and tried to use rebase interactive like before. But the commits appeared at the end of the current checked out branch. (I know how to and I had reset my repositories to the state before rebasing.) After some reading I

I have a repo in which I have two branches, master and master-old , which was created as an orphan branch. Now I want to rebase the entirety of master onto master-old , but the tree of each commit should stay unchanged, i.e. the working copies of each commit on master and master-old should look exactly the same way before and after the rebase. Current state ------------- A - B - C - D <--- master E - F - G - H <--- master-old Desired state ------------- E'- F'- G'- H'- A'- B'- C'- D' <--- master I tried to accomplish this using git rebase --onto master-old --root . The problem is, that in both

I am trying to figure out the working mechanism of git-rebase . Documentation provides information about what git-rebase does, but doesn't comment on how it does? I have looked into the source code , worked out some test cases and so far understand following: 1. Git maintains the state of rebase in .git/rebase-apply (with files like patch, final-commit, head-name etc) 2. Git uses git-format-patch to create all necessary patch files (which are inside rebase-apply) 3. Git uses git-am to apply those patches one by one I think I am missing quite a lot of details. Where can I find the