Thanks Alex - that's good to hear. In another thread I've just come
across the concept of "feature toggle" and I'm wondering if that might
be more appropriate for me.
Roddie
On 23/05/2013 11:01, Alex Lewis wrote:
Yes it really is a decision about the size of the project, the
complexity of the features, the dependencies between those features etc.
So essentially /Feature Branching/ won't fit every situation and I think
branching in general is more of a tool than a necessity and I think it
becomes a skill to "know" or to be confident when a branch is beneficial.
As you say in your case the feature branching model is not cost
effective so I'd go with whatever is cost effective and feels right for
you. In a small personal project I followed the GitFlow process as a
learning exercise but quickly saw that it was overkill for what I
needed. I typically just use the master and a "develop" branch and that
does the job nicely.
What I like is that Git and DVCS in general provide us the flexibility
to choose.
Cheers,
Alex
On Thursday, May 23, 2013 10:12:03 AM UTC+1, Roddie wrote:
On 23/05/2013 01:06, Yawar Amin wrote:
> Hi,
>
> On Wednesday, May 22, 2013 3:02:50 PM UTC-4, Roddie wrote:
>
> [...]
>
> That work is on hold because I have to get adverts on the
home page,
> and
> I've made a new branch - "adverts". This was branched from
the master
> branch, so does not include any of the work on "memlogin".
But I need
> the revised home page template file because the log-in form
affects the
> position of the adverts.
>
>
> You need to split up the `memlogin' branch commits into:
>
> A. a bunch of commits that change the size and positioning of the
login form
>
> B. a bunch of commits that implement the rest of the login form
changes
>
> Then you merge the `A' commits back into master.
>
> Then you branch off `adverts' from master and develop in parallel
> (because now you're working with the new layout/positioning).
>
> The main problem you have is, presumably, the commit(s) on your
> `memlogin' branch intersperse layout changes with functionality
changes.
> If you are clever with `git rebase -i' you can clean up the
commits and
> make branching work just fine.
>
> Of course, please don't rebase if you've already pushed your
branches
> where others can clone/fetch them.
Thanks Yawar. You've clarified for me that using branching and commits
and merging can take quite a lot of planning and, in my context, this
level of effort simply isn't cost effective.
Git is great for all sorts of things, but I've yet to be convinced
about
the overhead of keeping it all organised.
Thanks
Roddie
--
You received this message because you are subscribed to the Google
Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
