使用一个远程服务器管理两个本地GIT仓库

Question

I have ended up with quiet a mess with my github repo, and I am looking for some advice on how to sort it out and prevent it from happening again in the future. I will start by saying I am a systems guy not a developer, but I am responsible for managing the repos.

My environment looks like this: 1 Development server, 1 production server, and 1 github repo.

My current problem is: Both dev and production servers are using the same github repo. One of our developers has pushed code directly into the github master, which is currently running on the dev server, in the mean time changes have been made locally to the prod server. The new code on the dev/remote is not production ready and I need to get the local changes from production into github and deployed on the dev server without overwriting the new code on dev.

I think the solution to prevent this from happening again is the make the developer use branches instead of pushing into the master, and not making anymore changes locally on production. Any tips or advice is greatly appropriated.

Answer 1

The easiest solution is to create a new branch, called production , pointing to the commit you want to be deployed on your production server, then check out that branch on the production server.

Developers are then free to push to master which is the default branch on Git. To update the production server to a newer version of the code, you can advance the production branch to the commit you want to deploy, push production to GitHub, then do a git pull on the production server.

You can configure GitHub to put restrictions on the production branch so that developers can't push to it, and only allow authorized people to modify that branch.

Answer 2

To sort out the current mess:

1. Get the code from the prod server pushed to GitHub. Since master currently has other stuff in it, we'll push to a new prod branch. On the prod server:

   a. git checkout -b prod to create a new prod branch.

   b. git commit to commit your changes to the local prod git repository.

   c. git push -u origin prod to push your code up to GitHub.

2. Now let's get that merged into master. On the dev machine:

   a. git checkout master and git pull to make sure you're up to date.

   b. git merge prod to merge the prod branch into the master branch.

   c. git push to push the merged master branch up to GitHub.

3. Now, you're left with a prod branch that represents production and a master branch that contains all your changes. It's up to you if you want to rename these, continue dev work on master, push master to prod, or whatever.

---

How to avoid this in the future:

• Never edit code on a production box.
• Any code that gets pushed to production should be tagged with a release version. If you don't have a versioning scheme, you should start. It doesn't need to be fancy - you can just start with 1 and go up from there if you want.
• Implement a release process. For example, master should contain only tested code that's ready to be released. And when the code is released, master is tagged and then the tag is deployed to production. Or something like that. Figure out what works for you.
• In conjunction with the release process, develop policies around where code should be pushed. Most organizations would have devs push to a branch like feature-a and then open a pull request to master once the code is tested and ready to go out.