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 ;)
Related
I am working on a completely different structure from the one on master branch, on a On Rails app in a local branch. I am comiting everything and then pushing my changes to a remote branch as well. At some point in future, I would like to integrate my changes back into master, but I want to make it even first, so I won't be behind it, just ahead by n commits. If I am doing a
git pull origin master
into my branch and then push that, would I loose anything from my previous commits, or would those stay on top of the master branch ones? In theory I should be able to merge my branch, as I will only be ahead of master, but I am not entirely sure if that's how git is working
Never do significant work on the master branch. The only time you are really working on the master branch is when you are merging or if you are the lone programmer on a project (even then its questionable).
When working on a feature or taking care of a bug you want to be working on a separate branch.
For example when I take an issue from the product tracker I create a topical branch based on the name of the issue:
git checkout -b 136-fix-something-important
If the work on a topical branch takes a long time you keep up to date with the remote by pulling the changes into the master branch and rebasing your topical branch off master.
git status # make sure you have a clean slate otherwise stash or commit
git checkout master
git pull
git checkout 136-fix-something-important
git rebase master
This would fast-forward 136-fix-something-important if there are no conflicts or you would have to resolve the conflicts. However taking care of conflicts is better done early that later in a mega merge.
When you are done with the feature in your topical branch you either merge it (if you are a maintainer) or send a pull request (if you are a contributor).
So what do I do now?
Move your work to a separate branch. And reset your local master branch from origin/master:
git branch mybranchname
git reset --hard origin/master
git checkout mybranchname
You can the rebase your work in mybranchname off master.
git rebase master
Other answers aren't wrong, but it would be cleanest to push to a remote branch, pull to local master from remote master, then locally merge master into your local feature branch.
Then, your changes wouldn't be lost, merge conflicts could easily be resolved, and you won't rewrite any other potentially collaborative history with rebase.
you will not lose data when you do a PULL but you will get merge issues which you will need to fix.
While technically you can push without pulling (with --force flag), you should not do that, because it discards other people's work. First pull their changes, resolve conflicts and only then you can push.
Piece of advice, try to make your units of work small, as in don't spend too much time away from master especially if master gets updated frequently. The reason is that you will have a very difficult time merging.
A collaborator on a heroku app Im working on pushed some code, moments before I made a push, as the owner I rolled back the app, but now I can not seem to download the code to the my local repository?
I've tried rebasing the branch, fetching and reseting the HEAD, everything said it is up todate? I even deleted the whole local repository as a last resort and clones the app, is rolling it back in Heroku causing the problem?
When I do heroku releases I try to git checkout <deploy of collaborator> and I get a pathspec error
can`t you see his commit in reflog (git reflog)? if it is the case ask him to push again or push to a feature branch and cherry pick the commit you needed in to your branch
I have run into trouble with a recent production (well, staging actually but we'll keep calling it 'production') deployment.
I'd like to (read: need to) roll back the deploy to a previous commit. Actually, I'd like to go back a ways and then move forward cap deploying each commit one by one until I see the problem materialize. I know I can use cap -S revision=8c9ffa787b22cff019b27f71194637aa85506f9c deploy to deploy a specific commit.
My question is, when I FIND the commit I want to stick with how can I reset HEAD and master, etc. so that basically, master points to that commit and, ideally, all the subsequent commits are captured in a new branch of some name, say rabbithole?
Need to do this w/out fouling the git repos in development, GitHub and then the cached-copy that Capistrano automatically creates on production server.
Hope I'm making sense. If not please ask for more information.
Thanks!
I'd say you want to revert all commits between you stable commit and you HEAD. Check this
git checkout master
git revert XXSHAXX..HEAD
Where XXSHAXX is your stable commit.
This will create a bunch of new commits - one for each after stable. As a result you'll have a new commit equivalent to you stable in HEAD and none of your history will be lost.
P.S. and you wont be beaten by others who works in same repo.
To rollback to a previous commit
cap deploy:rollback
To rollback to a previously deployed commit
cap deploy:rollback:code
Once you've found a commit that you want to keep at master, you can do a rebase. Not sure if this is the best route, as you should always be wary of forcing an update on master.
I would temporarily change the branch where my staging environment is pulling from, rather than push a forced update on master upstream.
Ok, warnings aside:
$ git checkout master; git checkout -b master-backup-before-rebase; git checkout master
There might be a quicker/simpler way to do this, but we basically ensure we're on master, create a new branch called master-backup-before-rebase, and then go back to master.
$ git rebase -i head~XXX
Replace ~XXX with however many commits back you want to remove + 1.
Next, a text editor window will open - remove the lines of all commits you want to delete. Save, and close the window.
$ git push origin master -f
Voila.
Be very careful with this, and ensure that your backup branch exists before rebasing, lest you accidentally remain on the Master branch because you had uncommitted local changes or something.
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.
I'm still figuring GitHub and Heroku out, so please bear with me. :)
I've a web app on, say, xyz.com. What I am doing now is to make some code/UI changes on some files, commit those files, push them to the master branch, and then refreshing the url to see these changes.
I think this is obviously the wrong approach, but I don't know of how else to test changes done to my code without having to push them on to the master branch. How could I do so?
I don't quite understand the situation in the full version of your question (see my comment and, as icc asks, why can't you test locally?), but to answer the question in the title, you can see the differences between your master and the version on GitHub by running:
git fetch github
git diff github/master master
(That's assuming that the remote that refers to your GitHub repository is called github - it might well be origin in your case. You can see all your remotes with git remote -v.)
To explain that a little further, when you run git fetch github, git will update all your so-called "remote-tracking branches" - in most cases those are the ones that look like origin/whatever, github/experiment, etc. Those are like a cache of the state of those branches, and they're only updated when you run git fetch or successfully git push to that branch on the remote repository. So, once you've done this to make sure that github/master is a recent snapshot of that branch on GitHub, you can happily compare it with your local master branch using git diff.
First: You don't push to the master branch, you push to a remote repo. You should probably read up on your git.
Second: This is not a good workflow, first you should commit your changes and then test them locally. When you are done testing you are ready to push your commits to a remote repo.