On Tue, 13 May 2014 06:39:51 -0700 (PDT)
Alain <raf.n...@gmail.com> wrote:

> i'm learning how to setup/use Git. So in other words, i'm reading a
> book about Git 
> e.g. on my laptop i have a GIT repository as following:
> C:\repositories\git\
> so in this folder/directory i have the following things:
> C:\repositories\git\.git\
> C:\repositories\git\.gitignore
> C:\repositories\git\documentation\
> C:\repositories\git\website1\
> C:\repositories\git\website2\

Yes, "C:\repositories\git" appears to be a normal (as opposed to "bare")
repository: the directory itself is the repository's "work tree" -- the
place where files are checked out, and from where `git add` takes them
to prepare the next commit, and the ".git" subdirectory contains the
repository's data storage and local configuration.

(Bare repositories, which usually exist only for storage/rendez-vouz
purposes -- as opposed to development -- do not have the work tree and
contain what the ".git" subdirectory or a normal repository contains.)

> to share my work with my friend, we use bitbucket as team. Now we
> would like to have similar structure in bitbucket, so:
> documentation\
> website1\
> website2\
> till now in the book i saw nothing about best methods to do that....

You have to understand several simple things up front:

* Any Git repository is self-contained and self-sufficient.
  It may communicate with any number of other Git repositories
  (by fetching commits from them and pushing commits to them)
  but they are not required to do so.

* The filesystem hierarchy contained in the work tree of a Git
  repository matches one-to-one with the hierarchy maintained
  in that repository.

  This one is kind of obvious ("what you commit is what you get
  on checkout") but this removes the doubt about getting the same
  hierarchy in the repository you're about to push your commits to.

* In Git, each commit in a repository refers to the whole state
  of the project that repository tracks.

* Since data exchange between different Git repositories is only
  concerned with commits (and other objects they reference),
  filesystem hierarchy of the project the source Git repository
  tracks does not came into play at all.  That is, you can't push
  the series of commits touching "documents" but not push those
  touching "website1"; you can only push branches and tags, and all
  these objects refer to the whole project's history.

As you can see, there's no point to be concerned with having the same
hierarchy of files and directories in the target repository: if you
push what you committed locally there, the receiving repository will
have your exact history, and these commits will obviously represent the
same series of states of the project your local repository tracks.
Should someone clone that remote repository then, and check out the
branch you've pushed, their work tree will contain the same directories
and files you've committed.

And be sure to read up on "remotes" and "remote branches" before
embarking on colaborating via a rendez-vouz repository (what you're
about to do).  The crucial bit of understand is that the local
repositories of you and your colleagues are not somehow subordinate to
your central repository -- they are all free standing and
self-contained, even though they track the same project and keep mostly
the same history.  Understanding this paradigm will help you
understanding the way repositories communicate.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to