My laptop died and I need to code from another computer.
I am working with Heroku and I want to get the latest version of code from Heroku to another machine.
I understood that it is very recommended to get a proper remote repository using GitHub or BitBucket.
I decided to try BitBucket.
While creating my account, it asks for the old URL of my git repo. Since my machine is dead, I was hoping to fill in the heroku URL but that didn't work.
Any ideas how to proceed?
The idea is that I could pull and push my changes from either machines (when my laptop comes from repair).
You can simply clone your Heroku repository to your local machine. Then add BitBucket as a remote and push the code there.
Find out the Heroku repo url on the settings page of your app
https://dashboard.heroku.com/apps/[APP]/settings
git clone git#heroku.com:[APP].git
git remote add bitbucket ssh://git#bitbucket.org/[ACCOUNT]/[REPO].git
git push bitbucket master
As I am new at this, I am not sure if this is how it should be -
I am making a webapp and using heroku for hosting
I want to have several developers working on the same code on github.
I'd like to have 2 servers on heroku - one for production and one for testing(is it also called staging?)
problem is I know what by doing git push heroku master from the webapp folder it will send it to the application to the heroku server which was setup in the first place.
How do I deploy to 2 different heroku instances from the same folder using git? Is it possible/ recommended?
When I push to github it's usually the master, should I have another branch for test?
Is there a way to transfer an app between heroku instances?
if there's a place where there is a recommended deployment routine for heroku and github I'd be happy to read it
When you run git push heroku master 'heroku' identifies the remote repository you are pushing to. In your case 'heroku' seems to be a reference to your production server. Similarly you probably have an 'origin' remote pointing to github.
If you list your git remotes you'll probably see something like this:
> git remote -v
heroku git#heroku.com:heroku_app_name.git (fetch)
heroku git#heroku.com:heroku_app_name.git (push)
origin git#github.com:your_github_org/repo_name.git (fetch)
origin git#github.com:your_github_org/repo_name.git (push)
To push to a different heroku app you can just add that app as a new git remote.
git remote add heroku-staging git#heroku.com:heroku_staging_app.git
Now you should be able to push to either remote as needed.
git push origin master //push to github
git push heroku-staging //deploy to staging
git push heroku master //deploy to production
In general I suggest that you should not be pushing to heroku manually. Hopefully you can have a continuous integration server watch github, run tests whenever you push changes, and deploy to staging only when your automated tests pass. You can then have a manually triggered CI task which pushes whichever commit is currently on staging to production as well (or even automate production deploys as well).
You can perform the same configuration using the heroku command line. That also gives you a good way to manage environment variables and other settings on both of your heroku apps:
https://devcenter.heroku.com/articles/multiple-environments
I am using heroku to host my application. With merges and rebases i got 2 different stages of my app.
Local master is different from master on heroku.
pushing to heroku master failed with:
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git#heroku.com:xxxxx.git'
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
is there a way to delete the heroku master?
then i can push it again to heroku master..
You can force push
git push --force origin master
That will overwrite remote master.
You can also delete remote branch by doing this
git push origin :master
Note the colon before branch name. This command says "take void from local machine and put this instead of remote branch 'master'"
In my case, I renamed the branch on Heroku from master to main, and I want to delete the old master branch. If I delete the remote master branch directly on Heroku, it will be rejected.
The only way I found working is based on this document to reset.
Assume your app name is my-app. You can reset by
heroku plugins:install heroku-repo
heroku repo:reset --app=my-app
Note this will remove all branches in Heroku. So you need push to Heroku again by
git push heroku main
I'm running an Apache web server and was wondering what's the best way to deploy changes (from github) to the web server?
/var/www/ right now is only writable by root.
Should I have my git project directly in /var/www/? (so it creates /var/www/.git/?)
However, when I need to run commands (i.e. sudo git push) wouldn't work (since my ssh keys are not under sudo).
Would I be better off making /var/www/ writable by myself (and not just root)? Or should I add ssh keys to the root user? Or should I do something else entirely?
Thanks.
I use rsync to sync the contents of my local machine with the server, and if you're just deploying to one server, then it's pretty simple (and Capistrano is overkill.). I put the following aliases in ~/.bash_profile:
alias eget='rsync -avie ssh matt#example.com:sites/example.com/www/ ~/Projects/example/example.com/www/ --exclude .DS_Store --exclude ".git*" --delete-after'
alias edep='rsync -avuie ssh ~/Projects/example/example.com/www/ matt#example.com:sites/example.com/www/ --exclude .DS_Store --exclude ".git*" --delay-updates --delete-after'
Then, from the git repo on my local machine. I do:
git commit -am 'commit some changes'
git pull --rebase # pull any new changes from remote (--rebase prevents an unnecessary merge commit.)
eget -n # confirm which files I've changed
If it looks fishy, I could do eget without the -n and then just do a git diff -w. Then, I could do git checkout -- path/to/file for the files I want to keep my changes for. Then, I commit the changes that were on the server that I didn't get yet. This would only happen if the files on the server are changing in a different way than from deployments. Otherwise, you know that your local version is always more up to date than the files on the server and so don't have to worry about overwriting things on the server that you don't yet have on your local. Continue...
edep -n # just see what files will be deployed/updated/etc.
edep # looks good. Deploy for real.
Done!
Check out the rsync(1) Mac OS X Manual Page for more info.
Another option is to use the Git post-receive hook. But, you'll have to install Git on the server to do that. Also, I recommend putting the .git directory outside of your public www directory for security & cleanliness reasons. You can do this with the Git core.worktree configuration option. For example, from ~/git/example.com.git, do git init --bare; git config core.worktree ~/sites/example.com/. That makes ~/git/example.com.git like the .git dir for ~/sites/example.com/.
Create a central repository, use the branching of git to create different branches for different purposes, and never serve all of your repository publicly, nor should you ever serve your .git directory publicly (since that's the same as serving everything you ever did with the code or put in the repository to the public). Off the top of my head, here are the steps I recommend, from my own experience:
Create a central/hub repository for the code. (optional, but recommended. Even better is using github.com for your central repository). You can then check out local copies for local deployments, e.g. when you want to recreate the site on your laptop. Not necessary, but very convenient and makes sure your site is portable. You can have a staging repository and staging branch for development purposes. You can also have a repo and branch for production purposes.
Create a explicitly public directory in the repository that is not the root of the repository: E.g. Create a /www/ or /served/ or /public/ directory within the repository. This is stuff that will be publicly available and indexable by search engines, so be careful what goes in there. Assume that anything that goes in there is public knowledge, cached for eternity, and will be the target of security vulnerability attacks (because that could easily be the truth).
Create the dev repository: git clone the central repository on the server (e.g. cd /home/tchal then git clone git#github.com:tchalvak/ninjawars.git ) , though ideally in a folder that has shared permissions for your developer group.
Create a symbolic link for you development site: cd /var/www/ , ln -s /url/to/shared/repository/public/ nickNameForDevSiteHere , creating a symbolic link to only the served/public files of the site, creating a simple development level site. (optional, but recommended). In that manner, the dev site can easily be accessible via some ip and a nickname, e.g. http://10.0.1.123/publicdevelopmentsitenickname without the need of a real domain name.
Specify the live & deployed code commit. You may well want to create a live-branch for whatever code is currently "live", just be aware that this branch will probably have to be forcibly overwritten periodically, e.g. git branch live-branch git push -f origin live-branch. Consider it a snapshot of your code, and not a branch that will stay stable.
When you're sure that the dev site has been tested well enough, either deploy the live-branch code manually, via a custom deploy script, or use a distinct repository with the live-branch checked out in it, serving only the explicitly public content, similar to the dev site.
create a virtualhost in apache for the domain name. For example, you could use something like:
<VirtualHost *>
ServerName greatdomain.com
ServerAlias www.greatdomain.com
DocumentRoot /srv/greatdomain/www/
</VirtualHost>
That's a huge topic, so if you're not clear on all of the details, I recommend getting into further research of setting up a virtualhost in apache.
Point your DNS for the domain name at the ip of the server.
In summary, you can pretty easily use git to deploy all of your code using specific-to-each-deployment-type branches. Won't help with syncing, for example, databases between deployments, but that is a step that you could figure out after you have things running, as a second tier of deploying a site, and do it manually in the meantime.
I imagine this is a pretty basic question but I haven't been able to find an answer anywhere.
I develop websites. In the past I've handled all the live files manually and it stinks, of course. I've been hoping Bazaar could add some power and organization to the way we work.
Right now, I work with a local server on my laptop and want to gracefully push data onto the live server. Currently, I'm doing the following:
Local machine:
bzr push sftp://user#server/path/to/project/BZR/live
On server:
rm -r /path/to/project/live
bzr branch /path/to/project/BZR/live
Is there anyway to get the Local files live from the push?
Otherwise, is a branch to the live path correct?
Is there anyway to get Bazaar to just update changed files in the live path so that I don't have to delete /live each time?
Right now I have to manually edit .htaccess with each upload. If I didn't have to delete /live, I imagine I could tell bzr to ignore it and all would take care of itself.
Thanks for your help!
-Nicky
Check bzr-upload plugin, and also push-and-update plugin.