Yeah, I wouldn't like it to keep saying certain things are not tracked. You
can add use .gitignore to exclude those folders. There are other ways
(.git/info/exclude or local, global ~/.gitignore), but this is probably the
best way for what you describe, because it's version-controlled (stuff in
the .git directory isn't) and it spreads across clones.
All those projects:
You haven't described why this is being done or how those copies are being
used. Are some of them read-only, or are they all under active development?
Are you backing up the repository, do you just want the latest version of
the product on each server, or both?
If you're just trying to automate the latest version getting pushed to your
servers, you can use a post-commit hook (.git/hooks) to clone, zip up the
working directory, delete the clone and copy the archive your servers.
Cloning is necessary because I assume it's a bare repo without a working
copy of its own. If they're all bare repos but only one is under active
development you can just automatically push to the remotes in order to
synchronise them (if they're all under active development, someone will
need to supervise a merge).
If they're all under active development (e.g. multiple teams contributing
to one big project), you need to have one to act as the canonical repo.
Each team could have a branch with their current version of the project,
with whatever changes/fixes they've made and they'd periodically merge
their changes back to master and co-ordinate with the other team to merge
those changes back in to their branch.
Does that help? I'm not entirely sure I understand what your setup is, but
I think that should help...
On Friday, 4 April 2014 19:09:08 UTC+2, Thomas Beardshear wrote:
> Anyone have any suggestions for using git for multiple projects?
> The concept of git seems clear for one large project, but when your
> applets are in multiple locations (departments vs server functions vs
> cloud-based vendor integrations), it gets a little vague especially for
> people that use it periodically.
> I used to simply ZIP each folder(collection of scripts/applets/programs),
> move the ZIP file to a backup folder, then modify a file. Works great but
> I'm zipping ALL files instead of just the ones that changed.
> This works great for multiple projects, multiple storage locations, etc...
> Now it's time to put it all together:
> Multiple Storage Locations:
> Here is a typical setup (with a SUBSET of folders and projects)
> Notice the UNRELATED folders. When I use GIT, it reports that they are
> unmonitored - when is perfectly fine that they are, but disturbing that
> they are listed as unmonitored, not to mention screen-cluttery...
> What "concepts" in git should be used to manage the different
> server/department project folders/subfolders?
> Branches are designed (as I understand it) to test code and maintain
> versions. But these are unrelated PROJECTS.
> Should I use a different GIT file for each server/department/vendor?
> Is there another "structure management" feature that I'm missing?
> (no third yada is necessary here...)
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
For more options, visit https://groups.google.com/d/optout.