I need to give someone my project code and I am considering two options, maybe there's a better way too.

Firstly, I thought I'd allow them to get it from GitHub.  My repo, however, is private.  So would I clone my repo and make this public and allow him to clone/download this?  I want to keep using my private repo privately.

Secondly, I though I could send him my zipped local repo tree, however, would this jeopardize my private repo's security, because it will contain the private repos GitHub data and might allow connections to be made.

Thank you,

Josheir

Sorry, I'm not understanding you.

What @_WeirdCat_ is saying is that you make a new tree with files that you want to publish, and zip that tree.

Alternatively, most archive tools can take a list of files that should be archived, so by making such a list, you don't need to make a new tree first. Obviously that will fail if you need to change contents of files (ie remove the prvate parts from it).

Either way, make the archive, then list what is in it before you publish that archive. Better safe than sorry.

Cloning your repo and publishing that clone likely fails your objective, as it would clone everything that's in the repo, including all the bits that should not be published.

I really wanted to send all the solution/project files to so he could just unzip it and it would work.  However I am wondering if I sent the files if it would send the entire local repo and if my remote repo would be accessible from it.

Joshua

And I just understood WeirdCat.

A git repository directory normally consists of two parts. The first part is the .git directory with the real repo, that is, all files throughout history of the project. The second part is a checkout of the files (for a particular branch, like "master"), that is, the files in their current form with or without your local edits, as well as any generated or created file that is not tracked in the repo. ie your working copy.

If you zip the directory entirely, you get both parts, the receiver of the zip has whatever your current state of the project files is, and the entire history. "git clone" copies only the .git part, the history. Then the receiver can use checkout to recreate the files from the .git directory.

The thing to remember is that every git clone + git checkout is a completely self-supported independent collection of files at the file system with their history. git does store some remote access pointers, but that's merely a name translation, from "origin" to something at github.

Actual access to remote git repos is managed outside git itself. git simply uses http(s) or its own git protocol to make a network connection with the remote git instance, and once established, they can exchange revisions between the local and the remote. As part of setting up the network connection however you need access credentials, and without proper credentials you don't get a connection.

Thus unless you store your credentials inside the directory with files or inside git (ie you send sufficient credentials along with the zip), a receiver has no access to your files (he has his own files complete with history upto the time of copying the directory). If you wanted the receiver access your github repo, you would have to add him as a contributor or developer to the project, which basically tells github to give the receiver some access credentials that fits their role.

Two last things:

- For more details on this, read about "distiributed version control system"

- git is extremely flexible, I just described the common / standard setup, but you can tweak it in many ways, and depending on your tweaks some things I stated may not be true in your case.

But if you want the person to work with your reposetory, e.g make fixes to your code, then a fork would do the trick for you. A fork is a full blown clone of your reposetory with all the files and history but into a new standalone reposetory. This way your person can also commit changes to his reposetory and send pull requests so you have the chance to cherry-pick the changes youw ant.

However, you should never store any important information like passwords or ssh-keys inside a reposetory. Such files should be backuped no question but not inside a code base. If your code needs access to anything, then the code should read this from a config file or directory on your maschine, not the reposetory

6 hours ago, Bregma said:

To make it that much easier, if you're using the Github product to host a copy of your git tree, you can just click on the big green button on your project page that says "Clone or Download" and download a zipfile containing the files of the current head of the currently selected branch. 

You can then send your acquaintance the zipfile.  No showing your privates, no danger of including your private SSH keys.

So, this will just download the most current solution of my chosen branch, is that what you mean by the current head?  Is there anything special I need to do to get this only, or do I just press the button to get this zip?

thanks,

Josheir