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.
Related
I am working on a Rails project!
Excuse for not adding .gitignore
I have accidentally committed and pushed 'database.yml' in to my feature branch. A pull request was created from the feature branch to master branch a few days ago and is not yet merged. There are multiple commits done as part of this pull request and the commit containing 'database.yml' is the fourth last commit.
Others are also working as part of this project and they are merging the changes to master and we are pulling those changes in to our feature branch in-between. Thus, in our feature branch, we have got commits from others which are done after the faulty commit.
so I wish to do a 'git rm' and 'git push' the same file again to resolve this issue (as the PR is not yet merged). Will that create problem?
If you remove the database.yml that will be another commit on top, and nobody will be affected.
Notice, however, that the database.yml will still be part of the history and can be accessed via git log. If that file contains sensitive information, it will be findable by others.
Delete the file from your local system then add the changes to a commit using
git add <FILE_PATH> command and then commit and push the changes and it should be fine.
The right way to remove it properly is to reverse the changes you made to the file and commit it.
Another, dirtier way, is to open the commit and remove the changes and force push it to the repo. But you need the proper rights for this. Others will also have problems if they try to pull changes then.
I'm wondering how this is possible.
I made quite a bit of changes to my rails project (deleted some stuff, edited files, added files, ...) as I implemented a whole new design.
And now I want to commit my project and push it to github
git merge new-view
git add .
git commit -am "implemented the new design"
git push origin master
Now when I pulled the changes on another computer I noticed that not all of my features were working. (for example the image slider wasn't functioning).
When I go trough the files, it looks like all the changes I made are there, but I must be missing something because both projects are not behaving in the same way!
Even when I clone the project again from github (on the original computer with the working projectfolder), the feature still doesn't work.
git clone projectname
Now in my old folder I can't push any other changes as status tells me that my branch is up to date with origin/master
git status
I figure that I can just delete the github project and upload it again, but that's obviously not the way this is supposed to be done.
Any ideas what could've gone wrong?
Make sure that no important files are being ignored- see this answer
Make sure everything is truly committed. git status and git status --cached
Make sure any databases are initialized, migrated and populated with the same data.
Check browser caching.
So i am learning to ever so slowly use git to get me the latest update of RestKit as the old version has retain cycles...fair enough HOWEVER, when i pull using the gitHub Client it does not give me the AFNetworking files, which i was then told use the command
git submodule update --init --recursive
which i do, problem is that i noticed that after running that i run
git submodule status
It has taken me off the master branch and put the HEAD back in thus reverting me to old stuff. and hence back to leaks and stuff.
So i thought maybe i could install using cocoapods or perhaps put a submodule within the restkit submodule for AFNetworking...all did not seem to work and now i have followed this guide How do I remove a submodule? up until the last step as i dont know what committing will do? i hope it does not commit the fact that i deleted everything onto the restkit site? i am so confused, initially all i wanted to do was switch the current branch submodule i have to the master.
Assistance would be much appreciated.
EDIT:
Okay as to answer what Commit does, commit only affects your copy of the repository and will in no way affect the remote "main" repository everyone else gets their code from, so in essence i was able to commit it, then run a brand new submodule from the branch i wanted, But the question still remains Is there a way to switch the branch you pull your data from when using the update with --recursive?
Simply go in th e RestKit directory and type:
git pull origin master
(if you use the master branch of course)
Also, if you need to update all your submodules, just go to the root of your project, and type:
git submodule foreach git pull
git submodule update is confusing, here what it really does:
When you invoke git submodule update it looks in the parent repository for a SHA for each submodule, goes into those submodules, and checks out the corresponding SHAs.
As would be the case if you checked out a SHA in a regular repository, this puts the submodule into a detached HEAD state.
EDIT
To switch branch of a submodule simply, let say 'development', simply do in the submodule git checkout development and then you should be able to do git pull origin development
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.
I had been using a Subversion for my source control, combined with git ONLY to deploy (push) to heroku. My pattern was: Update local working copy from latest master at remote subversion repository. Then do git commit and git push heroku (Git was set to ignore .svn stuff). This working copy I only used to push to heroku, I had another subversion folder for doing live development, and committing to the remote subversion repository for tracking.
I have now switched to git fully. I did a complete import from subversion into a new remote git repository. I've successfully been working on my local working copy of the git repo (origin), and pushing changes when it suits me (also collaborating with one other developer, but I basically run the operation).
MY Question:
I would now like to return to my OTHER git working copy that I had previously been using to push to heroku (that has .svn/ stuff in it as well). I'm thinking of just adding my new git repository as an [origin] entry in the .git/config.. pulling the latest changes from my new git remote, and pushing to heroku, but I'm wondering if it will freak out.
It will try and merge and get confused won't it? AND, even if the pull worked, will the heroku remote get confused about a push that originated from some new git repo?
I could clobber (delete) that working copy (used to push to heroku from subversion), and make a new clone of my new git repository, then add heroku to the .git/config. But I'm concerned pushing to heroku will still cause it to get confused, since I used to push from a different working copy.
Any advice would be great!
Thanks in advance!
If I understand you correctly, you want to switch back to the former SVN repository as your working copy, and you want to preserve the old SVN history?
There are a couple of options available.
Push the recent changes from the new Git repository to Heroku, then switch to the old repository and pull from Heroku. This will bring you old repository up to date.
Temporarily change the URL in the old repository's config file to point to the local path of the new repository. Pull the recent changes from there, and then revert back to the Heroku URL when done. This will also bring your old repository up to date.
The first option is the most expedient, and the second is the long way round. Either way, you will have the same net result of an up to date local repository containing all history. The surplus new repository can be disposed of in either case.
Edit:
To address your concerns about whether Heroku will care about the origin of the commit, in brief, no the repository on Heroku is another git repository that accepts commits from authenticated users.
As long as the credentials are correct, the originating repository does not matter. This is the beautiful thing about DVCS - there is not one controlling or corruptible repository - It is entirely possible for you to now clone from Heroku on another machine and continue work from there. As long as your credentials are the same, the history will show any and all commits you push, but does not care where from.
If your desire is to simply use a clean repository to work with, the new one will be the favorite. The old one can be deleted without ill effects.
To prove this - check the SHA-1 hashes for a commit in both new and old repositories, and you will see they are identical. The hash is unique for all commits, and can be used to check the code integrity at all times. There will never be more than one change for any given hash.
As a side note, the repository is portable in that it is entirely self contained, and can be moved around freely on your storage space, or even be used on external storage such as a USB thumb drive.