If you are running a large project such as a website or ansible server you will want to test new features before pushing them into production then something like the following setup may work for you.

For this example imagine your URL is spondonit.com and you want a development/staging site on a subdomain which is dev.spondonit.com

SetupFor websites

Create the website's domain and subdomain

spondonit.com dev.spondonit.com On remote serverconnectssh username@ipaddress Create the main repomkdir ~/projects/ace/ git init --bare workstation_parc

Alternatively

git init --bare spondonit.com clone your new main repo to your local machine.git clone ssh://username@server_ip/~/projects/ace/spondonit.com

This repo will be used for version control only. See the workflow section for usage once we set up all the repos required.

Connect to the serverssh username@server_ip create a staging repocd ~/projects/ace git init --bare staging.spondonit.com create a production repogit init --bare production.git

You should now have 2 repos on the server and 1 local clone.

deployment hooks

Next we setup some hooks that will be used to automatically populate the staging and production directories.

Create staging repo hook.

The staging hook will automatically pull and checkout the latest version of your website in the dev folder.

cd ~/projects/ace/staging.spondonit.com/hooks post-receive nano post-receive Content example

• #!/bin/sh
• GIT_WORK_TREE=../../dev git checkout -f master

ensure permissions

Since the hook is a bash script we need to ensure that it is executable.

chmod a+x post-receive related man excerptA combination of the letters ugoa controls which users' access to the file will be changed: the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). If none of these are given, the effect is as if a were given, but bits that are set in the umask are not affected. The operator + causes the selected file mode bits to be added to the existing file mode bits of each file; - causes them to be removed; and = causes them to be added and causes unmentioned bits to be removed except that a directory's unmentioned set user and group ID bits are not affected. setup the production repo hook

The production hook will be slightly different as it will deploy to the production website folder.

cd ~/projects/ace/production.spondonit.com/hooks post-receive nano post-receive Content example#!/bin/sh GIT_WORK_TREE=../../httpdocs git checkout -f master ensure permissions

Since the hook is a bash script we need to ensure that it is executable.

chmod a+x post-receive Local workstation repo

On your local clone, we will add two of the remote repositories

git remote add staging username@ipaddress/~/private/staging.git git remote add production username@ipaddress/~/private/production.git

and that is it.

Standard Workflow

We have three repos set up on our server. Our main repository along with one for staging and one for production

When developing on your workstation you will push every commit to the main repo to ensure that all commits are saved in a single repository.

pushing to the master

After making change on your local clone you run the following:

git add --all git commit -m 'added some awesome new features' git push origin master

git push origin master saves all changes to the main repo on the server but does not ever deploy any code as the main repository is used for version control only.

pushing to staging

When you want to test the changes made to your main repository you push them to the staging staging (dev.spondonit.com) repository and run the following:

git push staging master

The staging hook will be initiated and will automatically checkout these new files into the dev folder.

pushing to production

After intense testing on the staging server and once your changes are ready to be deployed to the production server you would run something like the following:

git push production master

The production hook will be initiated and all of the changes made will end up in the web (httpdocs) folder or other type of server's folder and will be live!

IMPORTANT

So, as long as you push to origin first every time you make changes, all other developers working on the same site or server will be able to pull your work keeping everyone on the same page.

BASIC GIT

For basic git operations for a Laravel project please follow the below video

https://www.youtube.com/watch?v=t020co_fROU