1

I want to start using a version control system (git) to manage having multiple website developers working on websites. This way, we can all see who made what changes and at what time.

I did some searching and found this guide on pushing code to a live server. My git knowledge doesn't really extend beyond simple commits and pushing/pulling so I have some questions about doing this.

Pushing code to a live server seems a bit risky. Would it be fine to keep the production code in a master branch and put new features/bug fixes into seperate branches. Then, other devs can pull in those branches and check them, etc, before merging them into master?

How can I manage permissions on the website docroot? If two different users are pushing their code to the server, how do I get those files to be owned by www-data:www-data when they're sent to the docroot?

Improve this question

1 Answer 1

Reset to default
2

First of all congratulations! Having a versioning control system for managing your code is always a good idea.

Your hunch is right, it's always good to have two separate copies of the repo, one for development and one for live deployment, you should assign a release manager for pushing live code or have some kind of procedure.

Let everyone push/pull from the devel repo and keep your prod repo protected, then whenever the code is good to go out just push all the necessary changes from the devel repo to the live repo and push from there to all the live servers.

About the permissions my recommendation is to always push as the user you're writing to, so if you're deploying via ssh cross keys from your deployment user (remember, should be separated from devel to avoid temptation) to your www-data user, if not just add another step in the deployment script to chown the files

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.