CODEWITHSUNDEEP
gitversion-controlself-hosting
David
David

Reputation: 23

Managing Branches For Self Hosted Repo and Testing

I realize this doesn't sound all too clear, but I am still confused myself. I'm going through the Git ebook, but am not 100% sure I have fully understood it. If anyone feels there is information missing, please let me know so I can supplement it.

As of the other week we now have set up a self hosted git repo and server. This repo is the master and is what is currently live in a Staging environment. From here, we redeploy to production manually when we are ready.

Right now (and how it has always been), to make changes, someone just access' the file and makes the needed changes on the server where it is live. There have been multiple instances of users saving over each other's work and lots of things get lost.

What we are looking to do: Create branches from this master to let people write code on, but if the branches could be stored locally on user machines, not on test server where master repo is, that would be ideal.

For testing code: What would be the way to do it? Would it be to push the changed file(s) from the local branch to the master and try it there? Would it actually be just creating multiple branches on the server, but locally switching to those branches?

Code cannot be tested independently of anything else, so it will need to be added to master/deployed version in any case.

I've been tasked with setting up git for our environment, so I am looking to make this as painless and straightforward as possible.

Upvotes: 2

Views: 179

Answers (1)

Obsidian Age
Obsidian Age

Reputation: 42364

Git and version control can be really confusing to set up at first, so I'll try to answer specific points from your question individually:

"[..] to make changes, someone just access' the file and makes the needed changes on the server [...]"

You'll definitely want to stop writing files directly to disk on your production servers. Ideally, you'll want to do is handle deployments automatically through a continuous integration server like Jenkins or TeamCity.

"[...] if the branches could be stored locally on user machines, not on test server where master repo is [...]"

That's the whole point of Git and version control. You would host your files on your Git repo, and have each of your developers clone a local copy of the repo (git clone). This allows them to work on their own isolated copy of the code, while occassionally pulling the latest changes from the origin. They would then push their changes back to the origin when code was complete.

"What we are looking to do: Create branches from this master to let people write code on".

Here you ask about Git Flow. You should create a single branch off of master called develop, and branch each of your feature branches off of develop. When an individual feature is completed, it should be merged back to develop.

Git Flow (simple)

The develop branch should be hooked up (ideally through CI) to be deployed out to your development and testing environments. You'll want to deploy develop to the development server whenever there's a change.

"For testing code: What would be the way to do it?"

"Code cannot be tested independently of anything else, so it will need to be added to master/deployed version in any case."

You want to test on develop. When all features in a release candidate (the group of changes you're ultimately looking to deploy to production) are complete, you'll want to deploy the develop branch to the testing environment. Here you can test this version of develop, while other developers are free to push later versions of develop to the development environment -- the test environment will not get updated.

After satisfied with the testing on the testing environment -- when you want to deploy code to production, you can finally merge develop back to master (ideally making use of a release branch if you're handling proper release schedules). master is then hooked up to your production environment.

By following Git Flow, you'll only ever deploy code to master after it has been thoroughly tested, and thus untested code will never make it into production.

Upvotes: 2

Related Questions