TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Git workflows - maintaining base applications and accessing new patches
  • Not strictly KO related, but I hope it's OK to ask about this here anyway. I'm new to git, having used subversion for a long time for code control for my projects. I mostly develop alone, but collaborate with up to five others sometimes. The vast majority of my work is intranet or web application based, so the systems I use and develop have fairly intensive ongoing support available.

    I'm wondering about two things. First, there are various files and in general a consistent base set of modules that I use for all my applications. Obviously the system and module files are fine as submodules as in the "working with git" page, but for files like the bootstrap, index, .htaccess, etc I'd like to be able to easily maintain all my applications against the latest stable kohana versions. I'd also like to be able to centrally track cross-application customisations - for example adding exception handling into bootstrap - so that all my projects can be kept consistent. I was thinking that the easiest way to do this might be to fork the Kohana template application to make my own template application, then fork that for each of my projects. That would then presumably allow me to merge in upstream changes from Kohana and my template app relatively easily while keeping application level changes (I would expect to do some manual conflict resolution). Some of my projects are closed-source, so I guess I'd need to work out how forking works outside github - I presume it's essentially just a clone with a remote repository setup? My closed-source stuff is generally things I use to make my day job easier and so it's not worth taking a paid github account.

    The second is that there are some bugfixes and new features tabled for 3.0.x and 3.1 that I'd like to have access to in my applications sooner rather than waiting for release, but I don't really want to go the whole hog and run against unstable. So long as I satisfy myself that any particular commit is stable and has all its dependencies applied (particularly for 3.1 commits where I guess I'd have to check it wasn't referring to other changed parts of the API) is it sensible to pick and choose specific commits to apply to my own kohana repository? So I'd always be running latest stable + a few cherrypicked things from the next release. If I understand git correctly, if I do pull in changes and then they're ultimately merged into kohana master my own repository will realise they've already been applied and cope automatically.

    I only discovered git when I discovered KO, and reading up I'm very excited by the possibilities it offers, but I just wanted to see whether those more experienced had any input on whether the way I'm thinking of using it is sensible and practical or whether there are pitfalls to look out for.
  • I recommend reading nvie's A successful Git branching model article and checking out git-flow. This is the git workflow we use here (with Kohana) and I've been using it at work too. It really helps you organize and manage your development and release processes.
  • Thanks @Isaiah, I found those excellent resources the other day and they were very useful. My question though is more about working with external code and - in git-flow terms - using my very own release branch of kohana with the latest stable + selected bugfix and feature branches merged in where there are things I don't want to wait for. And, the feasibility of forking all my apps from a common source rather than creating an identical blank structure for each and manually tracking my changes.to bootstrap for example into all apps.

    Within each project I'd definitely use the git-flow workflow you reference.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion