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.