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.
Related
So I have deployed my rails app on a VPS with Ubuntu Server and Apache,
following this tutorial . Everything is working perfectly except that I'm not sure on how to continue to develop my app, bitbucket is configured and working but I don't want to commit and push every time since I make a lot of try and errors. So I'm looking for an easy way to continue to develop and test.
I will appreciate any answers and recommendations , thank you.
You can keep building your into local machine.
Create a branch git checkout -b branch_name
You can make changes and test this branch.
git add -A
git commit -m "Suitable message"
git checkout master
git pull origin master
git merge branch_name
git push origin master
P.S : You can continue your development in master branch too.
I know that this question has been asked in many different forms, but I have yet to see the configuration that I want, so I'm throwing this out there.
What I want:
1. 2 clones of the master, so each has its own entire version of the project, so that one subdomain goes to his current work, and the other to mine so that we can both see the changes that we commit and push to the remote server in our respective remote clones.
We both have own local versions of our remote folders/clones.
Essentially we both have our own branches, that neither of us are ever committing to the master branch. My personal branch can be considered the master in this case, because I want him to be able to make his changes, me be able to see and test them on his subdomain, and them merge them into my own.
I also want him to be able to pull my latest commits to the remote server into his own remote clone, and then subsequently onto his local machine so he always has my latest code.
What are the best practices for this? As of now this is what we have been doing and it has been a huge hassle and makes me hate git.
I make changes locally, commit them, and then push to my remote folder of the same branch.
He merges his local folder/branch with the remote commits that I made.
Any commits hes made locally he then commits to his remote branch/subdomain. (This should mean that his remote branch also includes my changes that he merged since his remote folder should be an exact replica of his local machine)
Upon inspection and testing I say a feature is complete, and I then merge into my local branch/folder
I push to my remote branch/folder and everything is available to see on my domain.
Is this not the correct way of doing things? Any suggestions or advice greatly appreciated!
The essentials are that we each have our own branches, and can make additional branches for features and merge them into our own. And also that we each have exact replica copies of our local machines on the server in different folders that are pointed to by the webserver via subdomains so both can be viewed at the same time in different states.
I apologize in advance for the length of this, I just wanted to be as clear as possible.
What you've written is not extensible - add a third developer, and then what do you do?
Instead, have the following branches:
master (always clean, use only for deployment to production server)
staging (always clean)
acceptance (messy)
You create new branches from staging:
git checkout staging
git pull
git checkout -b feature/JF_my_new_feature_20141018
(use a unique set of initials so you know who wrote the branch, and datestamp the branch as well.)
When you're satisfied with your branch (and your tests run fine), you merge into acceptance and run tests there. When your coworkers (or your QA team, or whoever), have verified that the branch is good, you merge it into staging.
Everybody always creates new branches from staging, and nobody merges into staging without a thumbs-up from someone else.
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
I have a Rails app deployed on Heroku and I have a git repo that I'm currently working on with uncommitted code changes. In the meantime, I need to make changes to the source on Heroku independently of the local repo. Can I do the following:
Clone the Heroku git repo on the same development machine with a different app name though with the same account
Make changes to the new local repo
Commit those changes to the new local repo
Push those changes to the Heroku repo
Resume working on my original local repo
Will this approach work?
Yep, that workflow would work, or stash them - and don't forget if you do make a clone of the heroku repo you'll have made changes to a different clone of the repo and you'll need to make those changes in your original local repo.
In future I'd suggest that you assume that your 'master' branch is what's live on Heroku and branch of that to work in - you can even push this branch into a new app for testing purposes. This way bug fixes can be performed on your local master branch (or another branch and merged into master) and pushed to heroku and then when you've finished your new work you merge the branch back into master and deploy that to your live environment. I wrote a blog article on the subject a while back, here
I haven't used heroku but if I wanted to make changes to a deployed application while I had unsaved changes in my sandbox, I would do one of the following.
stash my local changes, cut a branch from the point where I want to make a fix, make it, deploy it, switch back to my original branch and pop from the stash.
Commit my unsaved changes (into the current branch - say work), cut a branch from the point where I want to make a fix, make my fix, deploy it, switch back to work, reset my HEAD to before my "temporary" commit and resume work.
Unless you're using git in an unconventional fashion, there's no need to make another clone.
If you clone the heroku repository to a separate directory, made changes and push it from there, then there is a possibility of conflicts later down the road.
If its only the issue with the uncommitted changes then certainly you can stash them using "git stash" and later retrieve it using "git stash pop".
My work-cycle: I always keep a master branch with the #1 rule "always push to Heroku after committing something to master". If I code on something that I do not want to deploy immediately, I have to branch.
I know this works not for all use cases, but having always a branch that is identical to the app that is productive on Heroku makes me sleep better ;)
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.