After Day 1, this will be the same for Windows, Mac and Linux. The real difference is that Linux and FreeBSD (i.e. Mac) ship with git built in. So you don't have to install. In Day 1, we're just going to get stuff installed.
Basic principles.Git is a version control system (VCS). It tracks changes you make in files and lets you manage when to grab a snapshot of those changes. That's the simplest view.
It also lets you create branches very cheaply compared to other version control system. This lets you deal with experimental code safely while keeping your production code clean. We'll deal with this around day 4 I think.
If you know another VCS like CVS or Subversion, you're probably used to thinking of a having a central repository and everyone checks out a working copy. Stop thinking that.
Git is more like a torrent server - every copy is a full copy and can become the repo just by you deciding it's the repo.
I mention this on Day 1 because it means you can use git effectively all within your project working directory. You do not need to set up an external repo or sync externally. You get huge advantages from doing so (backup and collaboration), but if you just want to track changes in your files, you don't need this.
Today's MissionOn Day 1, your mission, should you choose to accept it, is simply to get git running on your machine.
Let's Get Started!
A. Install git1. Download Git from
- http://git-scm.com/downloads (git and command line interface, aka CLI, only, this is what I used and what the rest of this assumes you used)
- https://git-for-windows.github.io/ (git, CLI, diff tool and client all in one - this is probably the way to go, but I don't think it existed when I installed git, so I didn't use it).
Either one will install git version 2.7.1 (in Feb 2016), so the choice is yours.
2. Install. You know how to do this. Use the defaults (choose "run only from git bash" etc).
3. Test that it's up and running.
- hit the Windows Start key and type "git[space]". You should get a list to choose from depending on whether you installed just the basic git or went for the git for Windows thing. Select "git bash"
- this will open a terminal window.
- Since you gentlemen are, ahem, past a certain age click in the upper left, open the options panel and select text. The font is set to 9pt. Change that to 8 + (your age/10).
- now that your tired old eyes can read the damn thing, type "git --version" in the window.
It should spit out 2.7.1.windows.2. If it does, you are now officially running git.
When you opened git bash from the Windows Start screen, you probably also saw
- Git GUI - a decent enough GUI client
- Git CMD - git via the Windows CMD. Since bash is so much better... enough said.
B. Optional. Install more clients
I spend almost all my time in the git command line and you already have a git GUI, albeit not a great one, installed. But since you are software addicts and since we're installing stuff and since some people genuinely find a git GUI to increase productivity and since this is going to require at least logging out and logging in, maybe a system restart, because of the Windows context menu integration, you might as well install a couple of clients.
One of these does have pretty good difftool integration. I just don't remember which one right now and everyone has their opinion on which one is better... sooo....
Some possibilities
-
Git extensions - the oldest Windows GUI for git and still my go to when there's something I want to see visually. http://gitextensions.github.io/
-
SourceTree - by Atlassian, the people you will meet around day 3 or 4 - https://www.sourcetreeapp.com/
-
Gitkraken - the latest and getting a lot of buzz. http://www.gitkraken.com/
-
lots more - https://git-scm.com/downloads/guis
Whew! That was taxing. Have a beer or a cup of coffee or your psychoactive fluid of choice, because the next step is going to be just as hard.
Before going too far down this rabbit-hole, I'm curious if this is something I need or will help me.
>You get huge advantages from doing so (backup and collaboration), but if you just want to track changes in your files, you don't need this.
- During our build and deploy phases, only one person is responsible or working the site at any given moment. Graphics first, then layout and responsive code is done, then site build out. It goes from one stage to the next, one person at a time. Not sure how collaboration using git could help?
- backup might be nice, especially if it handles the files plus mysql dbs. Is that an option?
- track file changes. Now this could be helpful for that junior designer who makes a css change and 2 hours later realizes it broke something somewhere else and has to revert the full two hours of work to fix it. Can this track that specific change and help them identify it and not lose the rest of the 2 hours' work?
>>curious if this is something I need
Can't answer that. It was worth 300 Hanoi beers, so I figured it was worth a starter post. From what you say, though, I think the friction of starting will be difficult to overcome.
Quoteonly one person is responsible or working the site at any given moment
Hmm.... I use git on everything, whether collaborative or not, but that's me. I find just for synching between server and local it's worth it
for me. Basically, it means I don't have to remember what I changed where.
Quotebackup might be nice
It isn't really a backup solution per se. It's not how I would use it. It provides some of that functionality, but commonly you do not track binaries in git, so you need a backup solution. I have had a couple of situations where I track binaries in a separate repository from the code repo, but that's kind of a special situation and most people will tell you not a best practice. The main reason is that git tracks file differences and with a binary it can't excise just differences, so each change means it saves a copy of the file. If you have binaries that change a lot, it bloats the repo.
Also, git does not automate anything and my feeling is that any backup process that isn't automated is a process destined to fail.
Quoteif it handles the files plus mysql dbs
No. Not the DB. You need something else for that. Either periodic SQL dumps to a directory that gets zipped up and archived as part of your normal process or, what I commonly do, is a script that just emails a daily (or weekly) backup of the database to a GMail address. Unless you have a lot of crap (revisions, meta data history) in a Wordpress DB, it's usually possible to email it as an attachment.
Quotetrack file changes.
This is the purpose of git. This is what it does. Yes, the case of the junior (or senior) designer who screws up could be one scenario.
Quotehas to revert the full two hours of work to fix it
So a normal git workflow is like this.
- you have your production branch. This is actually running your site and is mirrored to your dev platform.
- when you need to make a fix to the site, you create a new branch that will hold all your changes. This takes about 11 seconds. For example, let's say I was going to add an image gallery, I would simply type
git checkout -b galleryNow I'm on the gallery branch. My changes do not affect the production branch. I work away and work away and my gallery works.
Now I run, say, Selenium IDE and run my simple test suite (anyone can use this). Did anything break? Yup. Why? Debug, get the gallery working and the bug fixed.
My gallery is working, my tests are passing and all lights are green. I'm ready to push this to production.
git checkout prod
git merge gallery
git push origin prodThen I log into the server
git pull origin prod Oh crap! A week later, someone notices a new bug. I need to find out where that came from.
git logOkay, the last commit was #123edf32w
git diff 123edf32wOkay, I see what I changed that might have caused that bug.
git checkout -b galfixI do my work, text it, commit galfix, merge it into production and push it to the server.
>I use git on everything, whether collaborative or not, but that's me. I find just for synching between server and local it's worth it for me. Basically, it means I don't have to remember what I changed where.
I've seen that type of use mentioned very often. I love the idea of syncing, it takes off a lot of the load of worrying about which was the latest code. That said, it's been images and dbs that have been the biggest pita. Code, unless it is very elaborate, I can fix or find.
Git or svn is a matter of religion. It's a must have for any developer or team.
Versioning, backup, deployment etc.
Drastic: you will wonder how you ever lived without it. So pay attention
Holy sh##. That was Torben! This will be lost on most of you, but "When E.F. Hutton talks, people listen."
<added>
Sit up straight, Dras.
Quote from: Torben on February 23, 2016, 05:29:05 PM
Git or svn is a matter of religion.
I started with CVS and it was okay. I could make it work. Then had trouble adapting to SVN. It just never meshed with me. Then I found git and Praise the Lord, I am a convert.
>>lost on most of you
But any American above a certain age knows exactly what you're talking about.
Anyway, you guys let me know. My fingers don't need the typing exercise, but if you want to give git a whirl, just say you've completed the Day 1 assignment and I'll do Day 2 for zero Hanoi beers.
>>images
As I say, under some circumstances, I manage images with git. But if you care about images, why not rsync with periodic archiving (7 dailies, 4 weeklies, unlimited monthlies).
If you're talking a handful of site images on a relatively stable site, sure, put them in git. If you're talking about heaps and heaps of UGC, then that seems like a really bad idea (er, actually, it just plain is a really bad idea).
>>DBs
synch or backup? I assume synch, but that's a really hard problem. You can go master/slave and have replication, but then you get two copies of the same thing. When you screw up, you have two screwed up copies. No good. If you change branches on git, git has no way of knowing that it's using the wrong DB (usually that's fine unless you have changes that affect the DB).
If you have
- an automated DB dump every X (depending on how often the site changes)
- git commit history for major changes
You go back to your dev/test platform, roll back to Feb 3, 2016 for your code and pull your DB dump from Feb 3 (or 2 or 4 depending on which side of the commit it falls) and you are back to a known state. If the static files are important too because there have been deletions, you pull one of your archives.
One of my New Years resolutions is "Don't try to teach people who don't want to learn." If this doesn't sound like it will help you, no worries. Not my job to sell you on it. But if you want a kickstart, just post here that you're ready for Day 2 (I have at this moment no clue what happens on Day 2, but something will).
To be blunt, I'm waaay past my prime when it comes to site-building. I might develop 5 small sites from here on out, but I am still interested in what I DON'T know. Drastic? Your call.
Blunt is good. We all spend too much time looking at screens. No sense doing it for no purpose.
Ah! This brings me back to all our conversations about Subversion and fond memories of TortiseSVN and the like. The technology was somewhat in flux then and it seemed to me there wasn't a a definitive leader to go with. I've been caught out in the cold a few times by going all-in on a technology only to have it slowly fade away. My dabbling stopped there and I concentrated on syncs and backups to fill the void.
I know I've needed to get more into Git, but really needed the motivation. this topic would be of great interest to me. You've got at least one captive audience member here. I really need to get my Git shit together.
Quoteplus mysql dbs
One option is to keep track of structural database changes by creating a SQL patch files for each group of changes. Clearly a ball-ache, but allows version control of databases without storing entire databases full of data.
Quotefond memories of TortiseSVN
Then TortoiseGit is your friend. Nowhere near as pretty as GitKraken though. Thanks for the heads up on that.
Day 1 feels like the longest day of the year ;)
Well... I did Day 1 and said there would be no Day 2 unless people wanted it. Nobody did.
So Day 1 isn't the longest day. It's the only day.
To be clear, I do want it but am unable to give it my attn at the moment.
I plan to revive this when things settle down. (thanks for taking the time!)
Yeah, no worries. Just let me know... not a particularly good time for me either.
Torben, Git Days are like the opposite of Dog Years. There are 27 regular days per Git Day.
Good stuff Tom and thanks for taking the time. Once I get some sites up and running, I will pay attention.
I have been using SVN for almost 10 years. Motivated by this thread I seriously started to look into Git. For all active and new projects I'm now using Git. All major open source projects are hosted on Github, GitKraken is Awesome, SVN is now dead to me. Git rocks!
Quote from: Torben on April 27, 2016, 09:26:18 PM
SVN is now dead to me. Git rocks!
:-)
It's so easy to branch and merge and push and fetch and
I'm sure you've got all this already...
[new branch]
git checkout -b dev
[make changes and commit]
git add -A
git commit -m 'first changes on dev'
[6 days off. I'm on branch dev. Now what did I change again versus the live version?]
git diff live
[Whoa, that's a lot of changes. Just tell me which files actually changed?]
git diff dev master --name-only
[I'm lost. Did I make good commit messages?]
git log
[less detail please]
git log --oneline
[OK, I've got it. So live and master are in synch though right?]
git diff master live
[okay, let's merge dev into live and push this to the repo. First checkout live, pull down any changes, merge in our fix and push it to the live branch]
git checkout live
git pull origin live
git merge dev
git push origin live
*Note - some people say you should never use "git pull" which is actually a fetch and a merge. I got burned by this in a minor way recently because when the merge fails it's harder to back out of.