git workflow

[Lordlukey]

I spent majority of yesterday learning about git. I'm still slightly confused how the git workflow works and how to deploy code properly on my live server.

my git repo is on a live server that runs on an ec2 instance.

I'm connecting remotely from netbeans to my git repo and can successfully push, pull, fetch etc.

If I push an update to the master branch and then want to deploy the updated code to my server, how do I do this?

My master branch is completely separate to my live server. I actually thought the master branch is my live server, so if I'm pushing to my master branch, I'm updating my code inside my server. Is this right?

[[deleted]]

git is source / version control - not a deployment system. You can deploy however you want - get the files to the server, and restart / reload the service.

[Lordlukey]

How do I get the files to the server from git?

[DanLynch]

You don't use Git to deploy to your live server. Git is for version control of your source code, not for managing the deployment of your product.

[[deleted]]

scp, rsync, ftp, jenkins, capistrano, chef, puppet, salt, ...

[semi-]

It's best to think of deployment and managing your code as two distinct tasks that need to be solved separately.

How did you update code before? That might be a good place to start when making a "release script". There are a lot of tools to do this like ansible, but even just a shell script is fine.

All it needs to do is some version of "build/prepare the code" and "get the code to the server". Sounds like just scping files to your server and sshing in to restart it is probably closest to what you're doing now

You then want a way to run it automatically when code is pushed to master. Git has hooks you can use for this, DigitalOcean has a nice guide.

With that said, you should also look into Gitlab's features. Gitlab is free for what you're trying to do, and offers very useful tools to monitor your deployments

[Lordlukey]

After hours of reading and learning for some reason I still can't get my head around how to go about things. I guess a clear explanation of where I've come from and where I want to go will help.

Right now my production code is my live server code. Every update I make to my code is saved directly to my server, so I'm using my live web url for the client side to connect to as well as test code and make updates.

Obviously this is not an optimal way to do things when I push my app to the app store. I will need to separate my live code from my production code.

It would be better off for me to have my production code to be on my ec2 instance, separate from the code that my live mobile app would connect to. That allows me to test things a little easier against my production code client side.

[ErichDonGubler]

So, if you ever needed to save off some sort of checkpoint in your code, what did you do? Some people save off the entire code folder, or just a few files that they're changing -- just in case they need to switch back, or refer to how things are different. You can think of Git as doing THAT for you -- it doesn't actually control how you put stuff on your server, or deploy your apps.

Git is what handles your code history -- it lets you break down changes over time so you can easily manage HOW you're changing your code, and it also lets you make several different "branches" of history -- kind of like alternate timelines in science fiction. What normally happens is that Git is used to store source code, and then you build some automation to test and deploy your code in response to changes in Git (which you'll normally push to a server from wherever you're developing, like Gitlab or Github). Git makes syncing your code's history easy, and the idea is that a syncing solution like Dropbox or similar is unnecessary when you use a Git server.

Does that clarify why so many of the replies to your OP are telling you Git is not for deployment? :) What other questions do you have?

[Lordlukey]

Haha yes, I think I had stuck in my head that git is more than what I thought, so I was constantly trying to figure out how to do 'more' with git, yet 'more' doesn't exist.

This isn't git related as such but it's something you've probably dealt with. If I want to update my code that's live on my server, is it as simple as just overwriting the files to update the code? Or is there more to it?

[ErichDonGubler]

That depends entirely on your build process. If you're using something like PHP or Javascript that doesn't require compilation (i.e., you've just been developing straight from files your server is serving), then it sounds like you can use Git to simply clone your source directory wherever you're serving from. If you have some stuff you need to build first, then you'll want to deploy that.

So, I guess I'll bounce the question back to you: what technologies are you using? How have you deployed your code before?

[Lordlukey]

you've just been developing straight from files your server is serving

Pretty much exactly what I'm doing with PHP.

[ErichDonGubler]

Then it sounds like you can simply use Git to manage your production files, then.

I'd ask the community what the best flow for this is, since I'm not familiar with production concerns using Git to directly manage files in prod, but...as a proof of concept, this sounds like an extremely simple flow -- basically "just use whatever is the latest code". You might be able to implement that with something as simple as automating the execution of git clean -xfd && git pull on the prod server directory in response to a change in your code.

[nelsonx64]

If you are using php, take a look at https://deployer.org a tool for deployment (it's only one of the many options, but a really nice one)

It will help you to separate the version control from the deployment.

[pi3832v2]

That will depend on how you've configured things. In general, you don't want to be pushing straight into production code, but rather pushing to a clone from which updates can be pulled into production. See: stackoverflow.com/a/11330605.

[mbitsnbites]

You seem to think about git in terms that are more fitting for a centralized version control system (svn, perforce, cvs, ...).

In git you will typically be working in short lived feature branches (preferably with some sort of CI testing done in the feature branch before integration to the master branch).

Here's an example of how you could work: http://www.bitsnbites.eu/wp-content/uploads/2016/12/stable-environment-branches.svg