How to Push/Pull source code from BitBucket to Ubuntu Web Server

Just gotta say that this is not the best idea.  Your production code base should be pull-only.  The fact that you have to log in to the server to effect changes is a security measure you should not bypass without very good reasons.

That said, as long as you have the git service up and running, you should be able to do this from any other remote repo, with the proper credentials.  In terms of git, the commands you want will look something like this:

# you change a file
git add my/changed/file
git commit -m "An awesome commit message that explains everything"
git push my_remote_name my_branch_name

Select allOpen in new window

Normally, your canon branch is origin/master, so that last command would look like:

git push origin master

Select allOpen in new window

In more real-workflow terms, you should be changing a branch, pushing that branch up, merging into your dev branch, copying your dev branch to a test area until it is confirmed good, then merging the QA'd dev branch into your prod branch.

Thank you for your comment. I know this is not the best idea. It's also not the way we will continue to work but for now the site isnt live yet and many changes are made by just one developer (not me). The idea behind this all is that i can automate the deployment of webservers from the google cloud so that they get their copy of the new code once it's there.

Looking at the first piece of code; this will change the master/branch on the bitbucket server right? But how does the webserver know there is a new version of the code? Do i use webhooks for that, and does it use git pull?

With a web hook, BitBucket would send a notification to a URL you specify.  The handler of that URL would then be responsible for doing the needful.  

For example, you could have that URL lead to a script which polls BitBucket's API for the commit history.  If [latest_commit_date] > [server_commit_date], then `git pull`.  For your part, you would need to create that handler, and create the web hook.  Incidentally, this means your web server would be able to execute a shell command triggered by an HTTP request.  Personally, I would rather staple-gun my fingers to the table.

BitBucket uses git as the foundation of the platform, so I'm pretty sure all your possibilities will use standard git processes.

Full disclosure: I have never worked with BitBucket, so I'm unfamiliar with their platform's capabilities.  I'm presenting you with ideas gleaned from scanning their documentation.  You might want to wait for someone with more direct experience to chime in.

Thank you for you awnser Steve. I'm curious why you'd rather staple-gun your fingers to the table?

Maybe I'm looking at it all wrong but i just want to be prepared for the future. atm we are still in the developing fase. We got just one developer who is altering the code directly on our webserver. Atm this server is one of my own but we plan to migrate to the google cloud. We will use a sql mycloud instance in combination with an ubuntu server for the website running on compute engine.

 my thought was when the need for a second webserver comes i just clone one from my template and then use git to automaticly pull the source code so it's identical to the other webserver. then when a change is made to the master the webservers get notified and automaticly download the new code so they always have the laters build from the website and stay identical.

Am i looking at this wrong? I saw a application named Jenkins wich makes this possible quite easy (for as far as my knowledge of this topic goes)

I get what you are saying. maybe its better for me to only automate the test branch to the test server and manually trigger the master to the  production server.

one more thing. when running git init to set the location for the local repository on my webserver is it a smart thing to do this in 'final destination'  folder (/var/www/html/ for instance) of is it better to use a seperate folder and copy it afterwards to the right location?

I don't see a problem with init'ing the final destination.  The only benefit to having it in a separate directory would be if you actually did automate pushing changes to it...essentially a redundant test repo.

Steve exlpained how this can be done and why you shouldnt do it.