Our project has been using git for a week or so now, and we're all enjoying it a lot (usíng it in a tight collaborative group turns out to be quite a different git experience). To keep things as simple as possible, we do not do any rebasing or history modifications. But we did make a few mistakes in the first week. A few commits were made that shouldn't have been done, and we managed to merge a feature branch into the wrong integration branch (1.1 instead of 1.0). And we didn't find out about these things until they were long into our history.
Now I see a lot of warnings about rewriting history, but I'm not really sure I understand the dangers involved. We use a shared bare repository, and all branches are pushed there for backup.
I would expect that if you rewrite history (say remove a commit), the full list of subsequent commits will "loose" that commit (and maybe not compile/work). I would also expect that if this happens I could actually choose to fix this at the top of history (and just leave that part of history as non-compiling).
- If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands (i.e. will they "know that I have done it" if I did it well?)?
- Will any users with local changes that I do not know about be eligible for merge failures on git pull ?
- Am I missing anything essential here ?
Any references to articles/tutorials on this subject would also be really nice.