Sorry for such a noob question - new to git and ruby on rails.
I am on a school coding team writing an app in rails. One of the pull requests has a new database on it, but the migrations have not been run (rake db:migrate).
Should we run the migration on the branch first and then merge to master or merge to master and then do rake db:migrate on the master branch?
If you're checking someone's work (i.e. it's not your pull request, but they say it's ready and it's your job to merge it), then you should checkout the branch and test if the migrations are ok, because if you merge it to master (and push it, so everybody can get the update) and migrations are not ok, then everyone will be frustrated because of the broken master branch.
That's why I recommend to checkout the branch, run migrations, and then merge PR to the master and push it upstream.
If it's your pull request and you're sure that everything is fine (or you work alone on the project), then there's no specific order: just make sure you don't forget all the steps (merge and migrate).
When I do it myself I usually already have migrations applied (because I needed them for the work in my branch), so it's usually just the case of going to master and merge the branch.
It's better practice to:
run rake db:migrate
commit to repo
because db:migrate modifies your db/schema.rb file, which displays "current" state of the database. It's super important to have latest version of this file in your repo.
Also note the comment in db/schema.rb:
# It's strongly recommended to check this file into your version control system.
Hence the recommended order above.
You should always run your migrations before merging to master because you'll want to know if that code worked properly and everything is OK. Remember running a migration will change your db/schema.rb file and if something is incorrect the server won't start properly or something will fail.
As for whether or not to run the migration before you commit to the branch, that depends on what you're doing. If you're team coding and need to review work first, go ahead and commit, so others can check out the branch and review.
Why would someone open a pull request on a branch that has new migrations that haven't been run yet? How does the author of the pull request know that the migrations were written correctly?
If I were reviewing the pull request, I'd expect migrations to be run before merging the branch to master. Also, be sure that your schema.rb is getting checked in with the migrations.
Related
I have a branch that has a different schema than my master. When I try to rebase with master, I get a merge conflict error with the schemas. I understand that this is happening because my schema on my branch is different than the one on my master. This is because I was working on something else in another branch and had to run migrations. I then merged that branch with my master. So now my master has a new table in the schema which the branch I am working on has no idea. So when I try to rebase with master it gives me a conflict error. Is there a way for the branch to automatically merge and take up the latest schema from the master when I rebase? I know there is a code snippet which I can put in my config file and call it in my attributes file, however, this solution does not seem to work for me since my migrations were made before I put that code in the config file.
If schema.rb (or any file for that matter) changed since you created your branch then you would have to manually merge the conflict.
Conflict happens only when file from both the branches have new changes present around same line numbers.
Doing below like mentioned in another answer would make you lose the changes done in your current branch:
git rebase -Xtheirs the_branch_name
In case of schema.rb generally the version number line throws the conflict. You should always put the higher number of two versions:
ActiveRecord::Schema.define(version: 2017081234567)
Delete the schema file, apply migrations if there are any at this stade of the rebase, dump the new rails schema and git rebase --continue. Repeat when necessary.
Since schema.rb is automatically generated after each migration, the simplest way to resolve conflict is to remove this file, run
rake db:drop db:create db:migrate
and commit the changes.
Ok, Using capistrano 3.2 with Rails 4.2.
Put simply I want to have each release on the live server to have an intact git repo with it. I know Cap uses git to clone the files but afik it deletes the .git folder by default. I swear I had this working before on earlier versions of Capistrano but no amount of Docs or Googling is finding the right setting. Or if I had an odd version of Cap
And before I get jumped on with "Version control on live? Never make changes to live, develop on your dev server you idiot!?"
Having an active git repo on live is invaluable if something changes out of your control, or if there is an emergency you have no choice but to monkey patch. Because now you have the change shown up by git and you can commit it, and push it back into your central repo and have it go up stream neatly. Its saved my ass before and means I don't have to copy by hand what I know has fixed the "live" issue.
Anyway, justification over. Anyone know how?
I apologies for the simple question, I think it's unlucky google fu which has left me without an answer from searching for this. Searching "Capistrano leave git on live" or other such terms are swamped with using git to deploy.
Cheer in advance.
This would be non-trivial. Capistrano uses git archive piped through tar to create the release folder. Hypothetically, you could override the task which does this, but you would probably spend more effort than it would be worth. I would highly recommend that you look at just creating a workflow where you commit a hotfix and push again. We use a prod branch at which the production deploy points, thus you could commit the change to the prod branch and cap production deploy, then merge your change back down to your development branch.
If you do choose to try and override this, look at the Capistrano source for the git tasks. It uses the Git Strategy class, so you would need to subclass and override it, then override the task to use your class. Capistrano is basically just a subclass of Rake, so look for documentation around overriding a Rake task, e.g. Overriding rails' default rake tasks.
Good luck!
I hope this is an ok question for StackOverflow. If it isn't, let me know. Thanks!!
I have my first Rails app about to go production. I'm using GIT and Github for version control. And I'm using CAP to deploy to our own servers.
We have one server for Staging and one for Production.
So, lets say it's day one of production. And I'm also coding new features on my iMac. So, I'm making changes and saving to GIT, Github and staging.
But, then the users run into a small error that I need to make a quick fix on production.
Well, I've already started making major changes to the code and I don't want to put that into production.
How would I make the quick fix the users need?
Thanks for the help!
Ill assume you have a prod branch and a devel branch, and the tip of prod is what has been released to prod.
You can;
1. git stash all your current work if you havent committed it yet.
2. git checkout prod
3. Create a new branch for your hot fix, fix it, merge it back to prod and release it.
4. git checkout devel and git stash apply your stash if you need to.
5. git merge prod into your devel branch so it has the hot fix you just deployed.
If you dont have separate branches for prod and devel, now might be a good time to set them up :)
See the section 6.3 Stashing of the progit book.
http://git-scm.com/book
You may create a branch for fixies, fix a bug there, and update your application on production server with this branch. In some moment you will merge them (branches).
Just starting out with rails and git and have run across an issue where I had generated a model, however just for a start have decided to use scaffolding for my first attempt. In this case I ran the following command
rails destroy model company
I am working in a dev branch I have created, after running the above command i checked my repo with git status and it said that there were no changes to commit. I checked that my model.rb file had been removed, so switched to my master branch and ran the command:
git merge dev
however it says that everything is up to date, even though I have changes in my dev branch which doesn't seem to have registered in my git repo.
Have I done something wrong, or is there something I am misunderstanding with rails to do with the generate and destroy commands?
Say I create a branch (new_branch). In that branch, a migration (migration_1) is created.
Later, I switch back to master. I then create a migration (migration_2), push to Heroku, and run migrations on Heroku.
Later still, I merge new_branch into master, and then push master to Heroku.
When I try to run migrations on Heroku, won't migration_1 be skipped over and not run, because it was created before migration_2, which has already been run?
Each migration has a migration timestamp attached. The list of successfully applied migrations is stored in a schema table inside your Rails application.
When you run migration_2, this entry is added to the database. When migration_1 is merged, Rails will detect the change has not been applied yet because the entry is missing in the schema table, and will run it.