Found 32 results for tag "q"
July 2nd 2016 06:30 am
My journey to discovering
gitwas not an easy one. Since
gitwas not covered in my formal programming lessons, I had to learn "version control" the hard way - the very hard way.
When I started learning HTML back in 2001, I learned to save and modify local files only. In 2002, I learned PHP and MySQL by working on a team server, but version control was not introduced (
gitwas introduced to the world in 2005, but options like CVS or SVK weren't taught). My first local server came in 2004, when I learned to FTP files, instead of testing local files only.
I quickly updated to SSH'ing into the server and editing the direct code, and backuped the files using a combination of file extensions (such as
.bak, date stamps like
.20150515, and "Backup 20140523" folders).
...and I used this method up to about a year ago, when I took a
gitintro course online. Unfortunatly, I didn't quite understand the purpose of
gitbecause the demos kept talking about files that either already existed, or branches that were made by someone else - never really diving into the underlying purpose of
git, which was version control.
I also couldn't get used to the idea of uploading my database login information (along with other private code) to the public site GitHub, which is great for open-sourced projects (see mine here), but not great for a company version control backup. So I dabbled in
gitfor a while, until it hit me about a month ago: I could use
giton my own server(s) and not have to deal with private repositories on GitHub (or the prices).
So, I started using
giton my server for backups of projects site-wide. Then, I wanted to deal with errors on a non-production server basis (I didn't want the world to see my error testing, because that would be unprofessional). After getting a local Apache server, and MySQL server, and installing PHP (on Windows), I thought that I could use the GitHub software to create backups - but that was only for the GitHub site; I needed something to work with my own existing servers. Therefore, I installed Cygwin and got the Linux-enabled commands with
gitto my production server.
Overall, this is what I learned, and I hope it helps others:
(If you don't already have
gitset up on your remote server, then please do so by installing it - I recommend
sudo apt-get install -y git. Otherwise, this won't work, and it's just a bunch of lines of code)
hooksfolder deals with webhooks to automatically catch incoming files and do something with them (or at least, that's what I've discovered). To make the hooks run properly, you need a
post-receivefile, and this is what it should look like:
Once you have that set up, you can work on your local machine to create and modify files.
One important note: As I have learned, your Git folder is not your production folder. I had my
.gitfolder in my production folder of a project, and it was good for local editing, but not remote pulling. If your project folder (example:
project.git) is somewhere else, like your home folder, then you can use the
post-receivewebhook to automatically pull committed files to the production area
Bonus: SSH Login w/o PW
Unless you want to type in your login information every time you
git push, I recommend setting it up so your local machine/development server can automatically upload to the production server. If you are running a Linux system (and I recommend you do), then you can do the following:
There is still quite a lot I don't understand about
git(like branches, merging, etc), but I am getting better. I've been using this guide as a resource, as many other guides are very technical for a non-
My takeaway: Better integration into team development instead of just "solo development"