I'm new to programming, learnt languages but this part I have no clue.
I'm working on a app that is on bitbucket and on Heroku cloud.
I am not exactly very clear how the bibucket repository interacts with Heroku and also my local offline commandprompt+sublimetext+PG database.
So what I'm doing is i have made some changes physically on Bitbucket (manually on their website) based on the changes Ive made and viewed (offline on localhost 3000) and wanted to push it to Heroku to have the changes online. There does not seem to be any buttons on bitbucket for that purposes and I guess I have to do it through the command prompt.
In that case how do I make those changes (command lines) and update the sublime+PG on the local server? I seen a few codes on git and suspect those are it (like git push -v) which lists the repositories but I don't wish to test and end up screwing the codes. Please advise if there are easier to do any of the above.
Note that I want the changes to be on Heroku because of this error.
Rails 4 Relationship Issue extended
Also what the difference between pulling and pushing changes? I'm reading the git definitions but it isn't saying much. Just that pull is pulling data from other repository to I'm not sure where. Push is to update remote refs with associated objects.
Many thanks!
Because you're new, let me explain what you need:
Heroku uses an amazing deployment process which based on the git scm
system. This means that you just need to "push" your git
respository to Heroku in order for it to deploy your latest revision
of code
The problem you cited is you're trying to push from bitbucket
directly. Bitbucket / github are essentially just cloud
repositories where you can store your code, and is not where Heroku
can "read" your files from
To get this working, as you've stated in your comments, you need to push from your computer. This is achieved by creating a remote repository for Heroku, and then pushing to that, like this:
$ git remote add heroku git#heroku.com:yourherokuapp.git
$ git add .
$ git commit -a -m "Latest Commit"
$ git push heroku master
Related
Here is the scenario:
1) My project partner and I were working on a Ruby on Rails app together using github as our code repo.
2) The app is under her github account and she had added me as a collaborator
3) She deployed to Heroku and added me as a collaborator there as well
4) I used the following command from my existing app directory with the intention of adding the existing Heroku remote app as a remote to my existing local app. My existing local app, as I mentioned before, already had a remote github
git remote add heroku git#heroku.com:codefellow.git
5) I made some changes and pushed them to github and all was up to date
6) Then I attempted to push to heroku with the following command
git push heroku master
7) This gave me an error saying the tip of my branch was behind, as shown below, but when I tried to pull from github, it said I was up to date, as also shown below
➜ code-fellows-alumni git:(master) git push heroku master
To git#heroku.com:codefellow.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git#heroku.com:codefellow.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
➜ code-fellows-alumni git:(master) git pull
Already up-to-date.
So does anyone know what is going on here? How could my local branch be out of sync with Heroku if I'm up to date with Github? Would it have been possible for my project partner to have pushed changes to Heroku without having pushed them to Github first? I checked and she does not have a fork of the application. I cannot get in touch with her at the moment to find out for sure what she might have done--I'm not even sure it would allow her to push changes to Heroku if they hadn't been pushed to Github yet. Any insights would be much appreciated. I don't want to clone the app from Heroku necessarily because I already have it locally synced with Github. I want to use Github as the code repository and I am reluctant to start from a clone from Heroku. I've already looked at the Heroku documentation on this: https://devcenter.heroku.com/articles/git. It just says to do a clone but I don't want to do that for the aforementioned reasons. I followed the directions given in the answer to this question (How to link a folder with an existing Heroku app) to get this far but it seems like there is a missing piece or else my project partner has done something unusual. Thanks in advance for any helpful ideas you might have.
The message you are seeing means that changes have been made to the application that you do not have in your local copy. When you push it's rejected because the Heroku remote is further ahead than yours, so you're right in thinking that your partner has pushed to Heroku without pushing to Github - it's a common scenario since you deploy from your local repository when you deploy to Heroku, unlike a traditional Capistrano deploy which would deploy the code from Github typically.
It's down to you as a team to come up with ways of working which prevent this from occuring, but if you need to get working right now, you can either
git push heroku master -f. This forces your changes and will overwrite what's there presently with your code
git pull heroku master to pull the changes from Heroku into your local repo which should then let you do a git push heroku master when you have the changes.
I got this error message (copied below) after trying to push to Heroku. I initially set up a facebook canvas app and selected the hosting on heroku options. It gave me a heroku url, which I added as a remote on the app I was developing on my machine
heroku git:remote -a desolate-springs-1684
But when I pushed, I got this error
error: failed to push some refs to 'git#heroku.com:desolate-springs-1684.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
localhost:nhl michaelmitchell$
So I did
git push -f heroku master
But now I apparently have to do a 'git pull'. However, what do i put after the 'git pull'? The name of the heroku url? or something else?
Forcing your git push was not a good idea because you lost any commit that was done by you or other collaborators you were missing on your working copy.
Before pushing, you should have either merged or rebased the upstream changes into your local working copy.
To merge the changes locally
$ git pull heroku master
$ git push heroku master
To rebase the changes locally
$ git pull --rebase heroku master
$ git push heroku master
BTW, now that you have pushed your changes, you actually don't need to do anything else. The remote repository already contains all your changes.
If for whatever reason the $ git status command is returning outdated references, simply run
$ git pull heroku
to fetch all the remote changes. Please note that unless you specify a target branch (or you have the tracking branch enabled), git pull will simply download (and not merge) the upstream changes.
Also note that Heroku should not be considered a git hosting. It means that it's extremely uncommon to perform a git pull from Heroku. Instead, you should use a git hosting (such as GitHub or BitBucket) to store your repository and only perform push to Heroku to deploy the application.
That error basically means that there is code in the repo that is newer than the code you're trying to push to it.
you have to do a pull and update your own working repository then push again, or just force a push
git pull heroku master
As a side note, if you aren't familiar with all the git commands, I would recommend you use a GUI as it may make the whole process a lot less overwhelming.
There are plenty of great clients here: http://git-scm.com/downloads/guis
Rails/Heroku/Git newbie - here is my question. I have an app deployed with Heroku and am using the git repository hosted there as the only remote copy of my local work. I start making changes locally on a new branch and want to make this branch available on Heroku so that I can continue work on it from another computer. Heroku ignores branches other than master and I don't want to merge my changes yet (or push them as master). Is there a way to store/access my new branch via my Heroku git repository, or is it better to have another remote git repository for my work in progress.
Thanks!
You can push a local branch to the remote git server with:
git push origin branch_name
That way, you can pull it down again elsewhere with:
git checkout -b branch_name origin/branch_name
http://gitready.com/beginner/2009/02/02/push-and-delete-branches.html
http://gitready.com/intermediate/2009/01/09/checkout-remote-tracked-branch.html
I would go with a separate git repository as suggested - github.com or similar. Store your code there and deploy to Heroku's master repo - Heroku is a hosting platform afterall not a home for your repos.
ALTERNATIVELY Make use of dropbox and create your local workspace in a dropbox folder that is synced across multiple computers - I employ this method as well as git - plus you get the advantage that Dropbox is versioned so if you delete/change a file that you haven't committed yet you can get it back.
I'm still figuring GitHub and Heroku out, so please bear with me. :)
I've a web app on, say, xyz.com. What I am doing now is to make some code/UI changes on some files, commit those files, push them to the master branch, and then refreshing the url to see these changes.
I think this is obviously the wrong approach, but I don't know of how else to test changes done to my code without having to push them on to the master branch. How could I do so?
I don't quite understand the situation in the full version of your question (see my comment and, as icc asks, why can't you test locally?), but to answer the question in the title, you can see the differences between your master and the version on GitHub by running:
git fetch github
git diff github/master master
(That's assuming that the remote that refers to your GitHub repository is called github - it might well be origin in your case. You can see all your remotes with git remote -v.)
To explain that a little further, when you run git fetch github, git will update all your so-called "remote-tracking branches" - in most cases those are the ones that look like origin/whatever, github/experiment, etc. Those are like a cache of the state of those branches, and they're only updated when you run git fetch or successfully git push to that branch on the remote repository. So, once you've done this to make sure that github/master is a recent snapshot of that branch on GitHub, you can happily compare it with your local master branch using git diff.
First: You don't push to the master branch, you push to a remote repo. You should probably read up on your git.
Second: This is not a good workflow, first you should commit your changes and then test them locally. When you are done testing you are ready to push your commits to a remote repo.
This is primarily a question about effective Git usage. I should first say I'm not an expert in Rails (at least in a production sense) and definitely a Git newbie, however, I have had some experience using SVN.
My problem is that I am trying to create a rails application but do not know the best way to keep development local on my computer but be able to deploy to my shared hosting account on Dreamhost.
I figured that Git would allow me to do this, but I am not completely sure how. I was thinking of creating a Git repo on the server and having my local stuff pushed onto it after each commit. I have read a few tutorials on Git, but am still confused on what to do. The alternative to this would be to just use FTP and copy over the files but that doesn't seem right.
Does anybody have a few first steps and/or commands that I can use? Is this deployment method fishy or is there a better way to do this?
I run a Rails website for a brass band in Wisconsin in a very similar setup to what you're describing, though it currently operates out of hostingrails.com. I host my code on github, though there's no reason you couldn't host it privately. My flow has evolved over the last year and a half, so take from this only what you need in the short term.
At the center of my flow, I have set up a semi-elaborate Capistrano script to handle the deployment, including a separate staging environment that makes a whole copy of the production database for testing. This took a while (hours, not days) to build, but it has been so worth it.
My workflow keeps at least 2 branches:
current_release: Live production code. Emergency bugfixes are made here.
master: Finished features ready for release. These features wait here to be tested live. Emergency bugfixes are merged in from current_release.
<feature_name>: Features under development. I try not to have more than 3 of these outstanding at any given time. Emergency bugfixes are merged in, and master is frequently merged in to keep the feature current.
Having this setup allows me to work on several things concurrently. Week-to-week (as this is nowhere near a full-time occupation), I do the following:
I edit in feature branches. I switch back and forth, get bored, get excited, whatever. Sometimes I merge two features that grow together.
[edit]
$ git commit
$ git push github [feature]
Finished features ready for iminent deployment are merged one-at-a-time to the master branch.
$ git checkout master
$ git merge [feature]
[fix immediate problems or inconsistencies]
$ git commit
$ git push github master
$ git branch -d [feature]
I stage the website to a private URL (happens to be stage.madisonbrass.com). The staging environment always pulls from the master branch.
$ cap staging deploy # master is now live at stage.madisonbrass.com
Bam, while I'm testing, I find an emergency bug on the public website. Fortunately, I have current_release working separately, and thus can separately fix and deploy it.
$ git checkout current_release
[fix bug]
$ git commit
$ git push github current_release
$ cap production deploy
I return to the master branch, and start by merging the emergency fix.
$ git checkout master
$ git merge current_release
I continue testing master. Hopefully no new issues appear, but if they do I fix them in master, I merge these changes into current_release and do another production deployment.
$ git checkout current_release
$ git merge master
$ git push github current_release
$ cap production deploy
I tear down my staging environment, lest it somehow get indexed by a search engine.
$ git staging teardown
What I do is have a shared, bare Git repository (created with git init --shared --bare) which is the "master" repository and is where I push my work. A bare repository does not have a working directory. For my web directory, I clone the master repository so it has a working directory and all the files are there. From there, I git pull any new work that I've committed.
I always do development work on a separate machine with a clone of the repository and a test development environment. When I've finished a feature, I push it up to the master and then log in to the production server and pull it to the working directory there.
This is just me for not-terribly-important projects. One could extend this with many more steps and checks and balances for Important Work.
I'd recommend using GitHub and keep your Dreamhost resources as free as you can to run your Rails app (in fact, depending on your project, I'll need as much as it can have to coup with it, being a shared hosting).
My usual workflow involves having a development environment and a GitHub account. We use Capistrano (which is fairly simple to learn and understand) to manage the push to GitHub, and then the respective deployment to the hosting, in your case Dreamhost, through SSH/SCP.
That way, you won't have to worry about what it's actually on your production repository, neither having to do maintenance tasks on it. Works pretty fast too and can easily be adapted for when you decide to change hostings o servers.