I've been doing a rebase of my branch ever since this thread started and ended up in quite a lot of hell with merge conflicts. Perhaps I shouldn't have done it on a branch that I was doing merges with. So I want to understand the workflow of the rebase. Is it something like this:
So I want to work on feature: 1. git co -b featureBranch 2. make my commits on day1 locally and push to remote/origin (?) 3. make my commits on day2 locally and push to remote/origin 4. decide to see the latest on master so do a git rebase master (resolve conflicts here) 5. make more changes to featureBranch on day3 and push to remote/origin 6. send in a squashed merge request for merging with master. How does this work if multiple people want to work on the aforementioned featureBranch? Does it work out this easily with everyone rebasing at will? If the fuss is about cleaner merge history then merge --no-ff will skip those annoying merge commits. I also find it easier to review the feature branch in logical chunks rather than one large patch. PS: rerere made the rebase conflicts easier but I wouldn't trust that with code I haven't touched. -- Prasanna.,
