i'm new to git - and trying to see how i can improve my work flow.

there are three locations of note:

1. the main repo that i keep in the cloud - which holds everything as backup
2. my local environment where i do work
3. a location on the cloud for others to only see the finished parts

how can i ensure that everything is backed up on to 1 and only the things i want shared are in 3?

i know that repos hold all history, so i don't just want to clone 1 into 3. i was thinking of making the FINISHED directory a submodule, but not sure if 3 should then be a master that i clone from and then push to...

what is the most efficient way of doing this?

1:.
├───.git
├───WORK_IN_PROGRESS
│   ├───.txt
│   └───.sql
│   └───.py
│   └───.csv
│   └───.blah
├───FINISHED
│   └───.git
│   └───.sql
│   └───.py

3:.
├───FINISHED
│   └───.git
│   └───.sql
│   └───.py

CodePudding user response：

Why aren't you using branches? Work in the feature branch and merge your finished work into the "Finished" branch. And send only the finished branch to the cloud.

CodePudding user response：

The Git answer to this question is "you don't".

Seriously, that's pretty much it. Git doesn't "do" compartmentalization: the repository is whole unto itself. Each clone of the repository is a full copy of everything. Everyone has full access to every file. Every commit stores every file. History consists of nothing but commits, and every commit is read-only, frozen in time forever: you only add new commits. If something is wrong somewhere, you add another commit. That's it! That's the end of the story.

Of course, like all simple and neat answers, it's wrong. Wrong here means not what people want, rather than incorrect, although this description is in fact incomplete—in part because people, being people, have added things to Git to make it do what they want:

• Shallow clones are those that omit some history.
• Partial clones—a still-new-ish feature that has a lot of sharp edges—are those that omit some objects so that the clone goes a lot faster initially and is much smaller, but they don't have all the history: they retrieve it on demand (and currently very poorly so).
• Submodules, which many call sob-modules because that's what they make people do when they use them, allow specific commits within a specific repository refer to other commits (by the commits' unique hash IDs) in other repositories.

These pieces can be used, in various fashions and with various limitations, to achieve the kind of compartmentalization you're talking about. But for the most part, if it's not absolutely required by some sort of external constraint, don't do it. You will regret it.