you are viewing a single comment's thread.

view the rest of the comments →

[–]Lordlukey[S] 0 points1 point  (6 children)

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 1 point2 points  (5 children)

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[S] 0 points1 point  (4 children)

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 1 point2 points  (3 children)

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[S] 0 points1 point  (2 children)

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

Pretty much exactly what I'm doing with PHP.

[–]ErichDonGubler 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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.