Jump to content
  • Advertisement
Josheir

C++ the Best way to Share a Project

Recommended Posts

Posted (edited)

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

Edited by Josheir

Share this post


Link to post
Share on other sites
Advertisement

Make a program that copies all source files but before that it makes a proper folder tree then clone it somewhere and then zip it

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, Shaarigan said:

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. 

Okay, so this allows me to keep my old repo, that's why I'm forking?  Do I need to set up permissions for the other users?  To set the fork up in Visual Studio I assume I just clone the fork and choose VS?   Could I just change my repo to public to do this, because like you said I would have control over what changes I accept?

Thank you,

Josheir

Edited by Josheir

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!