I’m new to rails and github and found such problem. I have cloned two projects to my first machine(work there sometime – made branches and all this stuff) and now I need to move these projects to my another machine – and I don’t know how to do it. I know that I can again clone this projects on my second machine but it didn’t save my branches. Can somebody give me any advices. Thanks for the help
P.s. Can I simply copy my projects folders from one machine on flashdrive and paste it to another machine?
yes you can simply copy that on flashdrive and paste it to another machine
You should also be able to accomplish this using the --bare and --mirror tags with git clone
git clone --mirror https://github.com/exampleuser/repository-to-mirror.git
# Make a bare mirrored clone of the repository
cd repository-to-mirror.git
git remote set-url --push origin https://github.com/exampleuser/mirrored
# Set the push location to your mirror
See this article form github for more info:
https://help.github.com/articles/duplicating-a-repository
And as #NitinJ said, from there you just run
rake db:create:all (or just enter the selected db's you want to create)
rake db:migrate
Related
My heroku repo grew to 1.5gb, so the nice fellows at heroku support cleared out the remote heroku repo and suggested I push a fresh copy.
However, the results of du -h .git locally show .git to be 276m. And, predictably, heroku throws an error when I try to push master to it.
So, my question: can I delete my local .git folder, do git init and push to heroku? What exactly would that do?
My app's code is pushed to github - my usual workflow is:
git add .
git commit -m "message"
git push #to github
git push heroku master
Possible Problems
There are two likely reasons your repository could be larger than expected.
You have a lot of binary assets in your repository.
You have a huge commit history.
Possible Solutions
If either of these things are the cause, you have a few options. Consider the following.
If your problem is binary assets, move your assets to an external asset store (e.g. Amazon S3 or a remote filesystem). You can then remove them from your history with git-filter-branch followed by git-gc. This will slim down your repository a lot.
If your problem is a really large history, make a separate shallow clone to push to Heroku. For example:
git clone --depth 1 my_repo heroku_repo
Well, you couldn't do that, unless you force a push (which is almost never recommended). This would erase your whole commit history and create a brand new repository.
But if you WANT to erase everything because of space... you can. It's just... strange.
What happens if you only push master?
You might want to do some housekeeping.
Do the upvoted answer but bear in mind that you can't push a shallow clone. Here's a follow up: Pushing to github after a shallow clone
I decided to learn how to use Version Control over Christmas break, so I downloaded Git, opened a GitHub account and started reading the online tutorial linked to from the GitHub website. When I got to this part http://progit.org/book/ch2-2.html I got stuck because I wasn't sure how to add files. For instance, I tried
git add C:/Finish.txt
And it said
Fatal: 'C:/Finish.txt' is outside repository
I was confused until I remember that a long time ago I had tried teaching myself Ruby on Rails and played around with Git back then. It never really went anywhere, but there's all this residual stuff floating around my system and I don't know how to change it. For instance, my Untracked files (which should be empty) are rails_projects/ and sample/.
How can I just erase all the old stuff and start over?
You should make a folder for your repository, move Finish.txt to that repository, then do git add.
For example:
# here you create C:\myrepo
cd C:\myrepo
git init .
# here you edit C:\myrepo\Finish.txt
git add Finish.txt
git commit -m "Added Finish.txt"
Start a new repository, e.g.
c:
md c:\newrepo
cd c:\newrepo
git init .
copy \Finish.txt .
git add Finish.txt
git commit -m "started over"
I strongly recommend against adding anything to C:\, let alone putting a git repo there. Unless of course you want to accidentally add all of your system disk to git :)
I can also heartily recommend using TortoiseGit which has some excellent explorer integration.
Delete any .git folder that you find in your drive.
To create a repo go to a folder that you want the repo in ( and not just randomly), do:
git init
Then proceed... Add only files that you put within this repo and not randomly from some location.
It would be very unusual to have the root directory of your hard drive be a git repository. That's probably why it's giving you the error.
git repositories are typically in a subdirectory and that subdirectory is typically a project.
To initialize a subdirectory as a git repository, you'd do:
git init (directory)
Then you'd add your files and commit.
In production, I maintain two sites - beta and release. Each points to a different directory via a soft link (e.g.)
beta_public_html -> /home/scott/myapp/trunk/public
public_html -> /home/scott/myapp/branches/1.2.3/public
I'm a longtime svn user, moving to git. I'm used to deploying via svn update and changing the soft link on a new branch, things are pretty simple.
Now I'm moving to git. I still need to have the two soft links (it's a Rails app using Passenger), though now I want them to point to two different git branches ("beta" and "release", say). And I want to be able to update them via git push (or git pull).
Question Part 1: I'm not sure the best way to do this.
The way I had started to do it was to just deploy to two different remotes, e.g.
git push ssh://scott#x.com/home/scott/myapp-beta beta
git push ssh://scott#x.com/home/scott/myapp-release release
But this doesn't work because push doesn't update the working tree by default.
So I go into the remote directories and run git reset --hard the first time, and it pulls the working tree. But I push again and I can't get the new push to show up - it just stays at the initial one.
(BTW, note that I can't seem to push to "myapp-beta.git" - that fails, I have to push to the directory name. I am worried that this is part of the problem, but I don't know what I did wrong here.)
So, if the answer to Question 1 is that my method is fine, Question Part 2: what's wrong with what I'm actually doing? If there are hooks I should be using, can someone point me to them?
(An answer to Question 1 that says "run these seven manual steps" will not be a terribly useful answer, seeing as svn checkout + ln -s are two steps.)
Thanks. I want to get back to writing code.
The article Git push is worse than worsless has an interesting discussion about a similar issue.
One of its solution and conclusion involves:
a bare repository on the production server
a cloned repository with a hook to pull what has been pushed into the bare one
So in your case,
one bare repo on which you can push beta and release branches
two cloned repo 'beta' and 'release' with a hook to pull their respective branches from the bare repo.
In short: one step: git push. No more link to manage (since the directory no longer represent a branch in Git, unlike SVN)
Regarding the hook part, a post-receive hook in the bare repo could be all what you need
See Git Tip: Auto update working tree via post-receive hook
$ cd bare
$ chmod +x .git/hooks/post-receive
with a post-receive hook like
#!/bin/sh
cd ../../beta
env -i git reset --hard
cd ../../release
env -i git reset --hard
Note:
the post-receive hook starts out with the GIT_DIR environment variable set to the repo/.git folder, so no matter what path you 'cd' into it will always try to run any following git commands there.
Fixing this is simply a matter of unsetting the GIT_DIR.
'env -i' does just that: it ignores the inherited environment completely and uses only the supplied variables and values.
The solution is to push to single repository, which would employ update or post-receive hook.
There are a few separate possibilities to create two checkouts, which can be used in hook (on server). Going from most lightweight:
If you don't need for those two checked out directories (checked out versions) to actually be git repositories, you can simply use git-archive to export two snapshots (two branches)
git archive --format=tar --prefix=public_html/ master | (cd /var/www/html && tar xf -)
git archive --format=tar --prefix=beta_public_html/ devel | (cd /var/www/html && tar xf -)
where 'master' and 'devel' are names of branches that you wanted to have checked out. Note that --format=tar is not strictly speaking needed, as tar format is default for "git archive". You might also want to remove old contents ("rm -rf public_html/" before "tar xf -" in first line, joined with "&&", and similarly for the second line).
Alternate way of exporting files would be to use low-level commands "git read-tree" (which writes tree to index) and "git checkout-index" (which copies files from index to working area).
In this solution the repository you push into can (and should) be bare, i.e. without working directory itself.
Another solution would be for the repository you push into to have two working directories, which can be created using git-new-workdir script from contrib/workdir. Each of those working areas would have be a checkout of appropriate branch of this repository.
Then update or post-receive hook would unset GIT_DIR, go to those working areas (public_html and beta_public_html), and do "git reset --hard" there.
In this solution "checkouts" would have some git-related metainfo in them (in hidden .git directory).
Yet another solution would be to have two (additional) slave repositories. Pushing into main (master) repository would then (via hook) either push into those two slave repositories, where their hooks would do "git reset --hard" or equivalent, or go to those two slave repositories and do a "git pull" from master there.
Those two slave repositories would be non-bare, and can be [directly in] public_html and beta_public_html. In this solution "checkouts" would be full-fledged git repositories itself.
You can improve this setup by having those slave repositories to have "alternates" (alternate object database) to point to master repository (i.e. be cloned with "git clone --shared ..."); without this object database in slaves starts hardlinked to master. This of course is possible only if master and slaves are on the same filesystem.
Note this solution allows for master repository to be on different host than slave repositories. (although I guess this is flexibility you don't need).
Finally you can instead of current setup deploy gitweb or some other git web interface (see InterfacesFrontendsAndTools and Gitweb wiki pages for a partial list), so that your users can browse different versions and different branches of your repository at their leisure.
In gitweb (and I guess also in other git web interface) thanks to path_info URL support you can view files in browser, and follow links correctly (if they are local), see e.g. git.html from 'html' branch of git.git repository at repo.or.cz.
P.S. "git push" does not update working directory in remote repository by default, because if somebody is working in the non-bare repository you push into, such sideways push can be very unexpected and lead to loss of work.
I use a post-receive hook like this to publish my website, because Git does not touch the working directory when doing a push. The remote repository is a non-bare repository, i.e. it has a working directory.
if [ -n $GIT_DIR ]; then
# Current dir is "<reporoot>/.git/", but we need to run reset at "<reporoot>/".
# Clearing GIT_DIR is needed, or reset will fail with "fatal: Not a git repository: '.'"
unset GIT_DIR
cd ..
fi
git reset --hard
(BTW, note that I can't seem to push to "myapp-beta.git" - that fails, I have to push to the directory name. I am worried that this is part of the problem, but I don't know what I did wrong here.)
When creating a bare Git repository (git init --bare) which does not have a working directory, it is a convention to name the directory "something.git". When having a non-bare repository, the repository is actually in the ".git" subdirectory, so the full path is "something/.git". It seems that in either case you can leave out the ".git" part and Git will detect it automatically.
I'm not really opposed to the other solutions, but I think there's a less hack'ish "Git way" to do this. Here's what I would do:
On my server, I'd set up a sort of a centralized repository (to be managed by Gitosis or some such thing).
From the client end, I'd constantly pull from the repository, make changes and push back. Branches are ofcourse, managed automatically.
I'd pull the required branch from Gitosis into public_html/ beta_public_html of the server. I'd keep it in sync with Gitosis periodically using a Cron job. If you don't like the Cron job idea, you could always use some sort of a hook + script as the others have pointed out.
I just started using Git and I want to know if this is the right way of using it. I started a Rails app with:
rails newapp
Then I did:
cd newapp
git init
git add .
git commit -a
So is it "right" to init my git inside my working directory?
Yes. You can place a git repository anywhere - including the invisible .git directory created by another git repository. I have a friend who has git track all his system config files in case he makes a mistake.
When working on a project, you want to init your repository in the root directory of the project.
To elaborate, each "working copy" of a Git repository is itself a Git repository. If you have a remote copy on a server, that is also a repository. You don't "check out" from there - rather, you "push" your changes and they are merged. If working on a purely personal project, the remote repository is often unnecessary. If you do want to host remotely, Github is a good, free, public choice.
Yep. Looks good to me.
Yes. In a DCVS like git, your working copy is your repository.
I am developing some school grading software and decided to use Github to host the project. After building some code on my Ubuntu box I pushed it to Github and then cloned it down to my MacBook Pro. After editing the code on the MBP I pushed it back to Github. The next morning I tried to update my repo on the Ubuntu box with a git pull and it gave me all kinds of trouble.
Whats the best way to work in this situation? I don't want to fork my own repo and I don't really want to send myself emails or pull requests. Why can't I just treat Github like a master and push/pull from it onto all of my personal repos on different computers?
I'll assume your problem was that the machine on which you first created the repo crapped out when you tried to issue the git pull command.
When you clone an existing git repository (like you did on your 2nd machine, the MacBook Pro), you're automatically set up to so your git pull commands will automatically merge the remote with your local changes.
However, when you initially create a repo and then share it on a remote repository, you have to issue a few commands to make things as automated as a on cloned repo.
# GitHub gives you that instruction, you've already done that
# git remote add origin git#github.com:user_name/repo_name.git
# GitHub doesn't specify the following instructions
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
These last few instructions configure git so future git pull's from this repo will merge all remote changes automatically.
The following is a bit of shameless self-promotion. If you use Ruby, I have created a Ruby-based tool that lets you deal with all these kinds of things with git remote branches. The tool is called, unsurprisingly, git_remote_branch :-)
If you don't use Ruby, my tool is probably gonna be too much of a hassle to install. What you can do is look at an old post on my blog, where most of the stuff grb can do for you was explicitly shown. Whip out your git notes file :-)
You can also add multiple SSH public keys.