cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From prasanna <srivatsav.prasa...@gmail.com>
Subject Re: [DISCUSS] git rebase vs git merge in your feature branch?
Date Sun, 31 Mar 2013 16:47:28 GMT
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.,

Mime
View raw message