From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: hs_glw <greg@hra.net>
Cc: git@vger.kernel.org
Subject: Re: Big Mess--How to use Git to resolve
Date: Wed, 21 Dec 2011 17:44:59 -0600 [thread overview]
Message-ID: <4EF26F7B.90206@gmail.com> (raw)
In-Reply-To: <1324147247781-7104493.post@n2.nabble.com>
On 12/17/2011 12:40 PM, hs_glw wrote:
> Randal, thank you for the comprehensive answer.
Note that Randal's solution leaves with a branch named Release that has
the history of the generic version of your software, and various
custom(er) branches that fork from the Release branch...
On 12/17/2011 6:32 AM, hs_glw wrote:
> Some clients have customizations of the code, some have version 5 of
> the software others have 5.2, 5.5 etc.
>
> My goal is to pull all the different versions in, put them all
> together, and create a master version of the software that runs for
> all clients.
Note that you don't have to make everyone run the same version. At my
shop we maintain dozens of concurrent divergent versions and that is the
main reason we chose git. We can maintain a generic version (which most
clients run) and also custom branches (for clients wanting to pay for
customizations) forked off of the generic branch. The custom branches
can periodically have the generic branch merged in to obtain the generic
fixes/enhancements. You can also merge the custom branches into the
generic branch if you want those custom features included in a new
release of the generic branch.
> There will still be some files that are completely unique to each
> client (style sheets and logos for instance).
If your logos are graphical files they are likely considered 'large
files' and are likely binary files in the context of git. It is
recommended you maintain these in a separate repository to keep them
from bogging down your main repo (performance and storage). You can
make the logo repo a submodule of the main repo (source repo). This
would then make your main repo a 'super project' (contains submodules)
in git terminology. Alternatively, I think your source repo and logo
repo can just both be submodules of a super project.
We are working on implementing this so some of what I said is
theoretical. Custom branches in combination with submodules seems like
it could get pretty unwieldy if not managed properly.
Some things to look into.
v/r,
neal
next prev parent reply other threads:[~2011-12-21 23:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 12:32 Big Mess--How to use Git to resolve hs_glw
2011-12-17 15:33 ` Randal L. Schwartz
2011-12-17 18:40 ` hs_glw
2011-12-19 17:04 ` Holger Hellmuth
2011-12-21 23:06 ` Neal Kreitzinger
2011-12-21 23:44 ` Neal Kreitzinger [this message]
2011-12-21 23:56 ` Seth Robertson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF26F7B.90206@gmail.com \
--to=nkreitzinger@gmail.com \
--cc=git@vger.kernel.org \
--cc=greg@hra.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).