CODEWITHSUNDEEP
gitrepository
user1232971
user1232971

Reputation: 111

How to start a github repository with a few versions that are in zip files

I am new to github and trying to start a repository. I keep searching for how to's on here but the the things people mention dont seem to exist and they dont link directly.

I installed git and did the git init/add/commit thing locally. worked ok. I also had previously created a repository on the website with an initial commit of the reade. Now that I have made two initial commits in two separate places, nothing seems to want to sync up. So I think I will delete the repository Dan start over.

While I'm doing that, I think I'd like to (if possible) start the repository based on an old zip of my code (i zip it up every release) and then upload the zip for each release so that I can have some history in the repository.

How would I go about doing that?

And what would have made the original repository sync up without so many errors? I got errors while pushing about non-fast-forward updates, and i got errors pulling about did I run git update-server-info on the server. Merging told me my URL did not point to a commit.

I looked at the documentation on git and that also seemed to reference things I couldnt find. All the local git commands seem to work, but nothing that involves communicating with the git server (github) seems to be.

Thanks for any guidance.

Upvotes: 2

Views: 1449

Answers (2)

Abizern
Abizern

Reputation: 150705

I think what you've done is created two independent git repositories - one locally and one on GitHub. They aren't going to match up because they don't know about each other.

What you should be doing is creating a repository on github, then cloning it locally, then making your changes and then pushing it to the remote on github.

Upvotes: 0

gotgenes
gotgenes

Reputation: 40049

This involves a little tedious work, but it's fairly simple to do.

  1. Gather all zip files of releases
  2. Unzip the project contents of the first release, which we'll call this release "v1.0", into a new directory called v1.0.
  3. Make a new directory, MyProjectRepository, and recursively copy the contents of v1.0 into this directory.
  4. Change into the top MyProjectRepository directory of unzipped project contents.
  5. Do git init .
  6. Use git add <filenames> to add all contents that you would like tracked in your git repository. (Note that there may be some files in your release (e.g., compiled .o/.dll files, .pyc files, etc.) that are not worth tracking. See this collection of gitignore files on GitHub to get an idea of what kind of files are not worth tracking in VCSes.) If you are certain all files are worth tracking, then you can simply do git add -f *) from the project root directory to recursively add all files and directories.
  7. Once you have added all files to be tracked, perform git commit, and add an appropriate commit message; if you can't think of one, simply state "Commit of version ."
  8. Unzip the contents of the next chronological release of your project, which we'll refer to as "v2.0", into a new directory called v2.0.
  9. Recursively copy the contents of the v2.0 direcotyr into the MyProjectRepository directory.
  10. Take note of any files that were removed in v2.0 that were present in v1.0; you can do this using the UNIX/GNU Linux diff command to compare directory contents (e.g., diff v1.0 v2.0) and looking for lines that say "Only in v1.0". For each of those files, do a git rm <filename> in your MyProjectRepository directory.
  11. In your MyProjectRepository, run git status to see what has changed. Note any new files that were in this next release that are untracked by Git. Add those that should be tracked using git add <filename>. (You could also use your diff results from the previous step to identify these files.)
  12. Once satisfied that you have removed all files that were removed in v2.0, and added any new files that appeared in v2.0, go ahead and perform git commit -a, and add an appropriate commit message.
  13. Repeat steps 8-12 for every subsequent release, in chronological order, until you've covered all releases. This can be tedious, so consider doing this only for major releases.
  14. Once you've done this for all releases, you're ready to push your project up to GitHub; follow the GitHub instructions on creating a new project, and then follow the directions for pushing a project which are also given to you by GitHub (if you get stuck, use the steps on this answer but skip the git init step — you already did this in step 5)

You will now have a repository of your project hosted on GitHub containing the history of changes between your releases that you can clone to other computers.

Upvotes: 1

Related Questions