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?
Related
I was trying to push my code (ruby on rails) stored in GitLab to production. As it didn't work, I tried to check git repository and accidentally created a new one through project/repo$ git init.
After that I got a message about Initializing a new repository.
According to other solutions for accident git init, it wouldn't be a problem if I initialized a new repository in already existing one, but in this case I would get the Reinitializing existing repository message, which I didn't get. So should I just delete the repository via rm -rf .git? According to this I accidentally started a new git init on an existing git project, what do I need to get it back to normal?, it will do me no good, or it might be different situation?
I have very little technical knowledge, so if you could explain "for dummies" that would be great!
Update: I deleted the repository and everything works now.
What the full message about "initializing a new repository"? In short, yes all git related files are stored in the .git directory so if you delete it you can start fresh. That sounds like a good idea considering that you won't loose anything yet.
Note that git init only sets up the repo to commit. You still need to make an initial commit in order to push to your remote on GitLab. You do this via git's commit command.
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.
I was playing with my local app, trying to add devise and railsadmin which was disastrous and frustrating. I decided that it's best I just nuke everything that changed and go back to my last working git commit. But somehow my local version is different than my heroku production ver.
How do I get or pull down my heroku version to my local - or get that commit? I am trying to figure it out with docs and CLI commands but things just aren't clicking. I don't exactly understand how the versions could be different. (I made CSS changes during my last commit and it seems my local is a version behind?)
Thank you.
How are you determining "the versions are different"?
As far as I know, if "git pull heroku master" says "already up-to-date", then the last commit on your current branch and the Heroku master branch are the same.
It is possible though that you have local changes which have not been committed to your local repo. In that case, git reset --hard HEAD will throw away your local changes and go back to your last commit. This should be the exact same commit as on Heroku.
(NOTE: only do this if you really want to throw away local uncommitted changes!)
I am working with RoR, and have recently cloned a project via GitHub. I have a specific RVM gemset for this project, but nothing inside of it. I am not sure if I should create a new branch and then run bundle install, or vice versa. My concern is I do not want to work on the master branch, but I know I need to set up everything first run bundle install.
What is the right method to get started on this project, with out breaking the master?
GitHub is just a hosting for git repositories. Well, writing just is not giving it proper justice.
However you should learn how truly git works. I heartily recommend reading free Git Book.
In short:
git is distributed
you're working only on local working copy
if you don't tell git specifically you want a file to be tracked - it won't (surprise, surprise!).
So running bundle install will not modify what is tracked by git and - specifically - won't affect remote master. It won't modify your master until you modify some files being already tracked. I think bundle install does not. And even then to modify remote master you need to commit and push changes.
You can work on your master. It's safe.
If its someone else's project, or an open-source project, you should Fork the project on Github. Then clone the fork. This will allow you to work on the project, commit your changes locally and push them back to the forked repository.
If it is your own project, and you do indeed want to work in a branch, then clone the repo and make a branch git checkout -b my_branchname. You will then work in the branch, check your code into the branch. Eventually you will want to merge this branch into the master branch. To do this you can merge locally:
git checkout master
git merge my_branchname
Or, you can create a pull request on Github and then merge the branch into master through the Github web UI.
The bundle command, used in conjunction with RVM will just install gems locally, most likely in your home directory (~/.rvm). Gems are not packaged with the rest of the code, so you don't need to fear messing up the master repo.
I have a pretty big problem. I am going through a Ruby on Rails tutorial, and they have suggested that I use GIT for version control. I have never used it before, and through the tutorial I don't think I used it right. Here is some back story.
I created a new project, and then I created a new Github repository. I named them the same thing, and I pushed my project to that repository. I then looked at Github, and all of my project files were there. I then went through a few chapters of the tutorial, and followed there instructions for pushing files to GIT. After awhile I realized, that none of my files were being uploaded. I didn't really care, so I went on with the tutorial. Still pushing files to GIT even though they were not showing up.
IMPORTANT
My Github repository only had the few files from when I first created it, the project on my local machine has a MANY more files. In the last chapter of the tutorial I was able to follow, it told me to do these commands:
$ git add .
$ git commit -m "Finish layout and routes"
$ git checkout master
$ git merge filling-in-layout
Once I did those commands, my project located on my local machine lost ALL of the files I created in the last couple of days. My guess is that Github replaced my files from my local machine with the files on Github (Just the files created when I started the project)
I think I have been adding files to GIT on my local machine since the folder '~/.git/logs/HEAD' has all of the commits I made, with what looks like GIT file numbers.
Any help would save me so many hours.
Thanks, -Chris
You committed some changes, then got the old version and reverted to it by issuing "git merge filling-in-layout". (you created a branch "filling-in-layout")
whatever you do DO NOT -> git reset --hard <- DO NOT.
what does "git branch" say?
do this:
git checkout master (or one of the others)
and look which one is yours. ;)
Erase github from your mind. It is irrelevant. The git repository is on your machine, inside your rails app folder. That is the beauty of git. So everything you have ever committed to git while working from that folder is there. It's possible you made some mistake along the way, or that the tutorial instructed you incorrectly, but you can look through all your commits with "git log", and then just go back to the point where things were good: checkout that commit (thus recreating the situation as it was at that moment), and pick up again from there.
Pedagogically I would suggest that you not try to learn git and rails simultaneously. They are both big and interesting, but they are completely orthogonal (that's fancy talk for "they have nothing to do with one another"). If you want to learn rails, learn rails. If you want to learn git, learn git. Just a suggestion.