2

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.

user1232971
  • 111
  • 1
  • 12
  • Hello and welcome to Stack Overflow! In the future, please include the text of any error messages you get in your question by copying and pasting. – gotgenes Aug 24 '12 at 14:58

2 Answers2

1

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.

Community
  • 1
  • 1
gotgenes
  • 38,661
  • 28
  • 100
  • 128
  • Thanks for laying this out clearly. This should be exactly what I needed. Its appreciated. Looks like the key was to do all local type commits and then a final push once all that work was done, I was to focussed on a push per commit. :) – user1232971 Aug 24 '12 at 15:53
0

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.

Abizern
  • 146,289
  • 39
  • 203
  • 257