I have an app that is live on Heroku/Github, but recently completely rebuilt it from scratch - I want to keep the old repository name, what is the best way to replace the live code with the new code?
Slight variation from Michael's answer:
git branch -M master old_master
git rm -rf .
git checkout --orphan master
git remote add version2 "/path/to/new_version/.git"
git pull version2 master
(as usual, back up everything first)
If you are using git1.7.2+, you can use git checkout --orphan:
Similar to -b, --orphan creates a new branch, but it starts without any commit.
After running "git checkout --orphan newbranch", you are on a new branch "newbranch", and the first commit you create from this state will start a new history without any ancestry.
When creating a branch whose trees have no resemblance to the ones from the original branch, it may be easier to start work on the new branch by untracking and removing all working tree files that came from the original branch, by running a 'git rm -rf .' immediately after running "checkout --orphan".
You avoid having two different history on the same branch, with an abrupt change at one specific commit.
Instead you keep several root branches with different history in it.
But that means rewriting the history of commits of master, which isn't that bad considering you only need the previous history for reference and archive only.
cd old_version
git rm -rf .
git commit -m "Removing the old code"
git remote add version2 "/path/to/new_version/.git"
git pull version2 master
That should fully preserve both histories and have the new version be the HEAD of orginal repo. I would recommend backing up repos up before you try this.
Related
I am new to git so please bear with me. I have a rails application on my local machine that I am experimenting with and pushing to the master branch periodically. It works at the moment, but I have fallen behind, and now I am many commits behind the master.
$ git branch
* master
$ git status
On branch master
Your branch is behind 'origin/master' by 27 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
nothing to commit, working tree clean
However, when I use git pull and then start rails, my application breaks with a precompiler error. So I am forced to use git --reset to go back to the local commit before I used git pull.
What is the right way to get around this issue and merge with the latest changes on the master branch? Would one use git --rebase in this case?
Try
git stash
git pull origin master
And once it updates, git stash apply to reapply your local changes
Since nobody has stated this clearly yet: You ask
What is the right way to get around this issue and merge with the latest changes on the master branch?
When you do git pull that does merge the remote changes into your current branch. Whether you would choose to do a rebase instead of a merge (per your other question) is a separate issue, but the default behavior is to combine the two sets of changes (local and remote).
More precisely, by default git pull does a fetch followed by a merge. The exact merge operation depends on configuration and on command-line options, but in a typical configuration where origin/master is upstream of master, saying
git pull
will merge origin/master into master.
So why the errors?
One possibility is that there were merge conflicts. If that happens, git will tell you. If you say git status in this condition, it will tell you that there's a merge in progress and it will indicate which paths (files) need conflict resolution.
Another possibility is that the changes don't conflict (in that they don't affect the same region of the same file) but still don't work properly together. That you would simply have to debug.
I am new to Git/Heroku/RoR, know basics of these technologies.
I have a git repository repoA which has two branches, master and feature.
I continued working on repoA/feature and upon completion, because the changes were huge so decided to launch a separate app on Heroku to test them first.
So deployed repoA/feature to repoTest/feature on Heroku. Then made some fixes to the feature and finalized the code in repoTest/feature.
Another developer made some commits in repoA/master during this time.
Now I want to make my repoTest/feature LIVE and MERGE it to repoA/master.
Please help me how can I do that ?
NOTE: I have tried doing git rebase master but that did nothing even after a long manual conflict resolve exercise.
As below steps are my normally operations:
1. git checkout repoA/feature
2. git fetch repoTest/feature; git merge repoTest/feature repoA/feature; git stash
3. git checkout repoA/master; git pull origin
4. git checkout repoA/feature; git rebase repoA/master (maybe here you should resolve your conflicts); git stash pop
5. git status; git commit -am ""; git push origin
I'm working on a new branch. Basically I've messed my code up and would like to go back to master and start fresh from a new branch.
Would $ git revert get me back to the master?
or should I be doing the following:
$ git branch -D branch-name
I want to get rid all the code and current entire branch that is checked out.
The online documentation is a bit confusing - scared to mess everything up.
To get back to the master branch simply use:
git checkout master
If you also want to blow away uncommitted changes you can follow that with:
git reset --hard
You can remove the unwanted branch using:
git branch -D branch-name
Yes, git branch -D branch-name would delete the given branch. The commits would remain in the repository until garbage-collected. Make sure that you don't have that branch checked out when you delete it. To do so, just check out master again with git checkout master, then you can run the delete command.
If you want to go back to master, just type in this:
git checkout master
Then start a new branch from there.
Try:
git checkout master
git branch -d messed-up-branch-name-goes-here
Other information may be found at the git book.
I have forked rails git://github.com/rails/rails.git at github. My forked repository is at git://github.com/waseem/rails.git. I want to test out some patches submitted by other users to rails mainline. Lets say I want to test out code in migration_status branch at git://github.com/joelmoss/rails.git.
Lets say I
master $ git remote add joelmoss git://github.com/joelmoss/rails.git. and
master $ git remote add mainline git://github.com/rails/rails.git.
I have been pulling from rails mainline into my master.
master $ git pull mainline master
According to http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#testing-patches I should create a local topic branch and pull in changes from joelmoss/migration_status. So I,
master $ git checkout -b migration_status Create a local topic branch.
And when I do:
migration_status $ git pull joelmoss migration_status
I get a large number of conflicts. I also tried migration_status $ git pull --rebase joelmoss migration_status but I still get conflicts.
In the case of pull --rebase, I think (correct if wrong), git is trying to apply my local changes on top of changes fetched from joelmoss/migration_status. Ideally it should do the opposite. To consider this option, I did following.
master $ git fetch joelmoss
master $ git checkout -b joel_migration_status joelmoss/migration_status and
joel_migration_status $ git rebase master it still gave me lots of conflicts.
How do I pull in patches submitted to one of my local topic branches w/o getting conflicts? I can not resolve those conflicts as I do not know much about what code to keep what not to.
In this case, it looks like joelmoss/migration_status is based off of 3.1.0, which split from mainline/master back in May. So if you merge you're trying to reconcile 4 months worth of development by everyone, in branches that appear to never have been intended to merge.
What you want to do is base your local changes on 3.1 as well. That doesn't guarantee to remove all conflicts, but at least it should be ones you are aware of because it's code you changed directly.
git checkout -b master-3-1 master
git rebase --onto joelmoss/migration_status mainline/master master-3-1
i use the git workflow as described in this blogpost.
In short: everybody develops inside his/her own branch, before merging back to master, you rebase your branch to master again to get clean history.
This works.
Now we have a submodule, and because this is an in-house plugin (Rails), we need to change this often. So most of the times i have changes both in the general branch and in the submodule branch.
What is the best way to work with submodules in the workflow as above.
I first try to push my changes to the submodule (git checkout master, git pull, git checkout branch, git rebase master, git checkout master, git merge branch).
Then, when i try to do the same for my root, i always get an error on my plugin (submodule). I have to resolve the error, before doing git rebase --continue. So if try to git mergetool i converts my folder to a file.
After the rebase has ended, i just restore the <folder_name>.orig to overwrite the file <folder_name> and all is well.
But somehow it feels there should be a better way.
In short: when working via checkout-b/rebase/merge - workflow, how do you handle the changed submodules simultaneously?
Whatever workflow you are following with submodules, there is one rule you shouldn't forget:
(From the Git tutorial)
If you want to make a change within a submodule, you should first check out a branch, make your changes, publish the change within the submodule, and then update the superproject to reference the new commit.
$ git checkout master
$ echo "adding a line again" >> a.txt
$ git commit -a -m "Updated the submodule from within the superproject."
$ git push
$ cd ..
$ git add a # There is a gotcha here. Read about it below.
$ git commit -m "Updated submodule a."
So did you commit the new state of your submodule within the parent project before attempting your rebase/merge from said parent project?