Git workflow for puppet development?
Brice Figureau
I'm facing a problem with the way I use git right now.
First, let me explain how I work:
1) When doing a feature or a bug fix, I'm creating a branch usually
called wip/<feature-name or ticket#>
2) I'm a big proponent of commit early, commit often, so I usually
produce a large number of commits in this branch.
3) Upon review or release, I create a feature/feature-name or
tickets/0.24.x/ticket-number on which I use git rebase -i to merge my
numerous commits to some larger commits.
Ok, all is great (except the rebase -i which I find painful when you
have dozens of commits), the issue is that when I have to perform a bug
fix or continue development.
I can't usually maintain 2 branches in parallel (because I don't want to
cherry-pick every single commits from branches to branches, and I'm not
so well organized), so I usually continue development on top of the
rebased branch (ie feature/ or tickets/ not wip), and then I have to
rebase -i again to merge the commits.
This is where things starts to really not work.
Then I push (forced because non fast-forward) again this rebased branch
for user to test or for review.
This is really cumbersome and users have no single chance to notice that
the branch has changed. Moreover I suspect that users pulling this
branch will get a reject (or maybe not?) since history has been
rewritten.
I'm seeking advice about this issue, so the question is: how the other
developper are managing their git development?
--
Brice Figureau
Days of Wonder http://www.daysofwonder.com/
Luke Kanies
>
> Hi,
>
> I'm facing a problem with the way I use git right now.
>
> First, let me explain how I work:
>
> 1) When doing a feature or a bug fix, I'm creating a branch usually
> called wip/<feature-name or ticket#>
>
> 2) I'm a big proponent of commit early, commit often, so I usually
> produce a large number of commits in this branch.
>
> 3) Upon review or release, I create a feature/feature-name or
> tickets/0.24.x/ticket-number on which I use git rebase -i to merge my
> numerous commits to some larger commits.
This is what I do, too, although I don't worry too much about
squashing commits with rebase.
>
> Ok, all is great (except the rebase -i which I find painful when you
> have dozens of commits), the issue is that when I have to perform a
> bug
> fix or continue development.
>
> I can't usually maintain 2 branches in parallel (because I don't
> want to
> cherry-pick every single commits from branches to branches, and I'm
> not
> so well organized), so I usually continue development on top of the
> rebased branch (ie feature/ or tickets/ not wip), and then I have to
> rebase -i again to merge the commits.
> This is where things starts to really not work.
>
> Then I push (forced because non fast-forward) again this rebased
> branch
> for user to test or for review.
>
> This is really cumbersome and users have no single chance to notice
> that
> the branch has changed. Moreover I suspect that users pulling this
> branch will get a reject (or maybe not?) since history has been
> rewritten.
>
> I'm seeking advice about this issue, so the question is: how the other
> developper are managing their git development?
I do the same thing -- commit, push, rebase, commit, push, etc.
I'm quite comfortable doing a git push -f and rewriting history.
Users pulling your code won't get an error unless they're trying to
merge your code -- if they're just doing a 'git pull', then there
should just be a notice, rather than an error.
So basically, I do what I think is the same process, but I don't find
it cumbersome. What, specifically, do you find cumbersome about it?
--
To have a right to do a thing is not at all the same as to be right
in doing it. -- G. K. Chesterton
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Brice Figureau
> On Nov 13, 2008, at 1:48 AM, Brice Figureau wrote:
>
> >
> > Hi,
> >
> > I'm facing a problem with the way I use git right now.
> >
> > First, let me explain how I work:
> >
> > 1) When doing a feature or a bug fix, I'm creating a branch usually
> > called wip/<feature-name or ticket#>
> >
> > 2) I'm a big proponent of commit early, commit often, so I usually
> > produce a large number of commits in this branch.
> >
> > 3) Upon review or release, I create a feature/feature-name or
> > tickets/0.24.x/ticket-number on which I use git rebase -i to merge my
> > numerous commits to some larger commits.
>
> This is what I do, too, although I don't worry too much about
> squashing commits with rebase.
I'm doing this because I think your (or James') repository shouldn't be
overflowed with tons of commits (with poor commit messages), and also
because I sometimes don't commit isolated changes that could be reverted
easily (which I think is an important property of all commits that will
end in the main repositories).
I think they'll get a [rejected] (non fast-forward), isn't it?
And in which case they won't get the last version, but if you don't
really look to the error message, you're stuck with an old version.
I'm pretty sure that's what just happened to James when he merged the
inline-doc changes today. He had to apply git black magic to resolve the
issue (sorry again for the headache) :-(
> So basically, I do what I think is the same process, but I don't find
> it cumbersome. What, specifically, do you find cumbersome about it?
Cumbersome might not be the right word, but it is error-prone.
Branches should always be fast-forward. That means I'll have to find
another git workflow or refrain to rebase -i when I find bug fixes.
Anyway I'll have to be more carefull with git.
Any ideas about this subject are welcome.