I am working with this school project (webapp in RoR) in group of 10 and we get into this fight.
One says we should use Heroku as our web host because it does version control with git.
The other says it's cool to use Heroku as web host, but it doesn't not store old code and keep track of changes, so we should set up our own github/assembla-git.
Who is right?
Heroku uses git for deploy. So you can use it as version control too.
But I would not recommend it. When you push to heroku it's mean deploy to production. But your code can be not ready for it. Not tested yet, feature not fully implemented and etc.
You can add 2 remote for your repository.
git push origin master # github
git push heroku master
So I would recommend you use heroku as webhost and github as version control
There is nothing wrong with using Heroku as your main Git repository. I have dozens of projects that are set up this way.
Heroku is definitely not going to arbitrarily delete code or commits in your repository.
Of course, anything you push to the master branch will actually be deployed, but you are free to push other branches if you want (Heroku will simply ignore those).
The advantage of using GitHub in addition to Heroku is that you get a bunch of extra functionality on top of just the bare Git repository, such as a web-based UI and collaboration tools like pull requests, etc. Keep in mind that GitHub for private repositories is a paid service, however. There are also competitors to GitHub such as Bitbucket which offers private repositories for free for small teams.
But if you are already familiar with Git and don’t feel like you need any extra functionality on top of it, you might as well just go with Heroku. There’s something to be said for simplicity, as well.
Related
I'm working in a rails project which uses SVN as central repository, but i'm working (locally) with git-svn, and I want to add a remote where i will only push master for testing purposes (i will push to Heroku).
I've read this from chapter 9.1 of Pro Git (my emphasis):
Don’t rewrite your history and try to push again, and don’t push to a
parallel Git repository to collaborate with fellow Git developers at
the same time. Subversion can have only a single linear history, and
confusing it is very easy. If you’re working with a team, and some are
using SVN and others are using Git, make sure everyone is using the
SVN server to collaborate — doing so will make your life easier.
I won't be collaborating with other Git developers (everyone else is using SVN), but before setting it up, i just want to be sure if there are any associated risks in doing this, and if so, what should/could i do about it.
If it's only for pushing to a repo so that you can then checkout/build/deploy, it won't hurt. That warning you noted is stated there so that you don't start moving around doing crazy things on the repo where you work with git-svn to relate to other developers also using git-svn (plus other restrictions) because of the way that revisions are kept on git-svn.
I'm beginner on rails, heroku and git, but I've done all installation stuffs.
I created two projects on heroku.com, but I don't know how to change them from my PC (the way I looked from help doesn't work such as "$ git push heroku master").
So, how can I edit one of my herokuapp in different computers?
As I understand, I need git commands to bound my projects on PC to herokuapp, and commands to update projects from heroku to my PC (mostly 2 different Win 7 and sometimes iMac). Am I right? Does anybody can tell me how it's works?
Thank you
If you haven't ever used a version control system before you might be in for a steep learning curve.
Git allows you to manage source revision across distributed repositories. In your case, it might make sense to set up a GitHub account and create a git repository there, then use that as your master repository. You use git to pull code from the master repository to your local machine, where you make your changes. You commit your changes to your local repository and then push these changes to the master repository.
On your heroku account you then git pull from the master repository to retrieve the changes you made.
This brushes over a lot of detail that you need to know. I suggest you start googling git tutorials and read up about how git works and how it's intended to be used.
If you are totally new to git and heroku i would suggest you to go through this
I have this confusion and perhaps it may be basic question. I am planning to work on a Rails project along with a friend who stays in a different location.
We have identified Heroku as our deployment platform and Bitbucket for SCM related activities.
Both me and my friend are new to rails but we are familiar with web development in general.
I m working on a Windows box while he is on a Mac. We both have the same rails version including the gems. However, I'm not sure really sure how do we manage the source code and code integration. The reason I say this is because, when we try to commit the entire code from our systems a few platform specific rails file gets uploaded on the server, thereby rendering the deployment useless.
So my question is if I am on Windows and my friend is on Mac, whats the recommended way of working together on a single RAILS project and deploy it on a common platform to get the same desired functionality.
Yes, by using the source control management (SCM) you selected when you set up your repository.
For instance, if you use git, you would copy your repository using git clone (the command is provided via the bitbucket interface by clicking on clone), make your changes, and then git push your changes back into the repository.
When you want to code next, execute a git pull command to get the latest repo changes and then work and git push your changes back to the repo.
For examples see Bitbuckets fantastic tutorial.
As a side note, bitbucket also supports mercurial, although I haven't used it.
As far as your actual issue, each person will need to make sure the platform dependent files are excluded from your repository. If you're using git, see the git book specifically the section on .gitignore and git rm
I'm trying to setup a decent development pattern with my friend. The plan is that we do independent development on our own computers, then push to the dev server for testing, and then we push from the dev server to the productive server (Heroku).
The problem is, I can't make git behave. Perhaps I just don't know enough to fundamentally understand what's happening. I've setup the repo on the dev server, but when I clone it to my personal computer, I can't "push" it back because it complains about pushing to a non-bare repo. So then I tried branching the repos, and pushing branches, but now I get a lot of fast-forward statements, and I don't think I want those either.
So my question is this. How do I setup the server so it all just "works"? The server cannot be a bare repo, it needs to have the code in it so we can test the app. We want to be able to push and pull from the repo to our own dev computers smoothly. And the server needs to be able to push to Heroku (it can do this already). This is on my own server, so I have complete access to whatever I need to get this working. (Ubuntu Server Edition 11.04).
Thanks!
The reason you can't push to a non-bare repository by default is that a non-bare repository has a checked-out working copy associated with it. When you push updates to the branch that is checked out, the working copy would become out of sync with its own repository, unless you specifically run a command to update it (which you can do using a post-receive hook). If you're aware of this and you would like to push to a non-bare repository anyway, you can set the receive.denyCurrentBranch configuration property to ignore and git will allow the pushes. For further details I refer you to a blog post I wrote some time ago (probably due for an update) which describes a similar setup that I use for my own website.
Note that instead of just development and production servers (each with their own non-bare repositories) I also have a third repository, a bare one, which I push changes to first, before sending them to dev; that way, I only ever push to the development server from one place, which helps keep things in sync.
To expound on #David Zaslavsky's comment, I would set up a bare repo to push to most of the time, then use something like git-deploy to push to your development server. You get the same semantics as pushing to Heroku, without Heroku.
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.