git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Repositories stucture
@ 2019-04-13  5:17 Mgr Georg Black
  2019-04-13 15:23 ` Mateusz Loskot
  0 siblings, 1 reply; 2+ messages in thread
From: Mgr Georg Black @ 2019-04-13  5:17 UTC (permalink / raw)
  To: git

Hello everyone.
We are starting knowing and working with Git. We already used some version control  systems for parts of our work and for now we wanna to have one.
So how's the situation. 
There is one big company with integration center and a few smaller firms which send their work there. We are developing in many languages on more projects.
People from big company(BC) wanna to have only one big repository with all code in it. BC wanna have to folders structure for language and projects. But for us is that idea bit uncomfortable because we rather have more repositories by language, maybe by project (in BC folders). It's useless for us that every developer on specific project and language have all other sources in their local repository. Is it the solvable?
I looked into some ways but with nothing practical experience Could anyone give me some advice which way is the best and why.
Simplified: we want to have many repositories in our firm so every developer could work with its repository with its language. Somewhere would be one repository for integration man who combine all smaller repositories in folders big repository for sending to BC. And this all have to work both ways. So we wanna donwnload changes from BC and copy them to our divides repos. So some folder to repo.
Thanks to all for any direction or link.
Georg Black



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Repositories stucture
  2019-04-13  5:17 Repositories stucture Mgr Georg Black
@ 2019-04-13 15:23 ` Mateusz Loskot
  0 siblings, 0 replies; 2+ messages in thread
From: Mateusz Loskot @ 2019-04-13 15:23 UTC (permalink / raw)
  To: git

On Sat, 13 Apr 2019 at 07:32, Mgr Georg Black <georg.black@seznam.cz> wrote:
> People from big company(BC) wanna to have only one big repository with all code in it. BC wanna have to folders structure for language and projects. But for us is that idea bit uncomfortable because we rather have more repositories by language, maybe by project (in BC folders). It's useless for us that every developer on specific project and language have all other sources in their local repository. Is it the solvable?

Show the BC how Boost libraries structure the repositories with submodules
There is single superproject https://github.com/boostorg/boost/
and large number of libraries (each with dedicated team of developers).
Periodically, everything is synchronised into the superproject repo
and prepared for release in single bundle.

Then, you may want to learn about submodule and subtree features of Git,
and choose the one that suits best your workflow(s) to implement your
repositories structure.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-13  5:17 Repositories stucture Mgr Georg Black
2019-04-13 15:23 ` Mateusz Loskot

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox