How would we begin using git when we currently have a dev and prod server?

Question

I'm in the process of implementing better version control practices within our company and I'm not entirely sure how to begin using git with the current situation that we have.

Right now we have a development and a production server. Changes are made to the development server directly and after they're tested and ready, we move them over to the production server via good 'ol SFTP drag & drop.

I would like to somehow implement git in this process (using GitHub) but I'm unsure where to start. Our development codebase is wildly different from our production one as we have 10-15 in-progress projects and bugfixes that can't or shouldn't be pushed yet.

How would we go about implementing this in a way that we can start using git without having to match our dev to production codebases first?

Answer 1

Branching/Feature Experiments

First off, if you have 10-15 in-progress projects, how are they co-operating with each-other now?

Git solves this problem by providing branches. So instead of projects being mixed in together and sharing problems, each experiment would be separated on it's own branch and would be based off of the master branch or the dev branch. This also has the benefit of making them much easier to merge if it comes to it.

Central Repository

So what is the recommended workflow? Simply enough, just use one central git repository.

I would say, base that central git repository off of the production code, and then port over the "experiments" that have promise. Or have the experimenters merge them in on new branches and then help them commit them and push the branches up.

Then, to update production, you would pull from the master branch. To update the development server, you would pull from the development branch. No more using SFTP. And feature branch experiments could either be switched to on development as necessary, or even better, could be used only on local copies that each developer is running and testing on themselves.

Localhost development

This is independent of git, per se, but is a big part of the picture that seems to be missing because y'all have been relying on SFTP, which isn't versioned: Once you have a versioning system in place, it no longer matters where the checkouts are hosted and where the commits are committed, as long as they get pushed up to the central repository. You can now host a localhost version of the website to run your experiments on. It will be fast. It will be accessible. And it won't break the development server or the live server until you actually pull commits down and update them, so you can experiment very freely and very powerfully, on local branches on a local machine. Assuming you're working with websites, you can just create a fully local copy with an alias into your hosts file. So I have a totally local website at http://nw.local that maps to a folder with a git repository in it. And if I want to experiment, I git branch experiment;git checkout experiment and then hack away and make commits, and if I like the results, I rebase or merge the commits onto the dev branch and push that. Then I often delete that branch, and start a new branch, with new or similar experimental features.

Answer 2

You’ve got a typical scenario and all under control. With git, it’s all the more simpler.

First off, I would suggest you have a central git repository. The production and development servers can be established as different branches of that central git repository. Now since you always deploy the production code using the production branch, let’s call that as the master branch of your central repo.

With that in place, let’s come to the development server. You first create another branch called dev and base it off the master branch. It reflects the latest stable release of your product and at any point in time the dev branch should be master + features that are going to be released. With this structure in place, you need to now establish a protocol to test and deploy all your projects that are in progress.

Now, let’s say a feature F is being worked on by an employee X. X can then create a new branch called branchFeatureF on his local. This needs to be created from the origin/master branch since that’s the stable version. X works on his feature for a couple of days and feels it’s ready to be tested. Good, now push that to the dev branch. It’s as good as pushing to the master, but since you are still in the testing phase, you are working on the dev branch to test it before it goes to master.

All the QA is done on the development branch. After any bug fixes, feature F is now ready to be released, so it’s time to merge the feature branch branchFeatureF into master and deploy your code - awesome.

Now the master has the feature F, so before you test another feature F’ by another employee X' on the dev branch, you will pull in the changes from the latest master with feature F and test that out. Of course, if the features aren’t conflicting with each other, F and F’ can be worked on simultaneously with X and X’ pushing to the dev branch and testing their respective features at once.

In essence, you are giving enough freedom to all your colleagues to work on their features by asking them to create their own feature branches but making sure that they always push to the dev branch and that the dev branch is always up to date with the latest master. This ensures no time is wasted figuring out any merge conflicts while merging the branches. You as a repo maintainer will take up the responsibility of merging the QA approved feature branches in master and deploying the code on production. No messing with the master branch.