Nolan Erck talks about "051 Git ColdFusion Source Control (Getting Started and Best Practices)" in this episode of ColdFusion Alive Podcast, with host Michaela Light.
Show notes
What is "source control" and when / why all CFers need it?
Repository = library for your code with versions baked in
For Windows, Mac, Linux dev
For any kind of code you write: CF, C++, Java, iPhone, Ruby, COBOL, PHP, QBASIC, InstallShield
Docker config info or CommandBox scripts
Database creation scripts
Even documentation or graphics fields
Though best with text files
Your desk or brain? (just kidding)
The problems of home made source control
Copying files to Bak or zip
Future Confusion and Deadwood code
Security issue
Team changes
Revert to an earlier version across multiple files
Why not just have everyone work directly on the production server? (bad idea)
Even a shared dev server is a bad idea
What is Git?
Server
GitHub, Bitbucket, Unfuddle, BeanStalk, host your own
Client
OSX: Tower, GitBox, SourceTree, SmartGit
Windows: TortoiseGit, SmartGit
Can mix/match among team members.
Free to $50
Why Git and Costs
Free options for server and client
Command line or GUI
Modern industry standard
Alternatives to Git
Subversion, CVS, Team Foundation Server, Visual SourceSafe, PerfForce, Mercurial.
How to use Git from a GUI
Allow 1-2 h to get started if you have never used Git
The difference between Git and GitHub
Git is the protocol
GitHub is one brand of Git server
Common Git commands
Add
Just because you make a file, that doesn't mean Git
watches it for changes.
Commit
The “committed” version of the file is stored locally.
Only file delta are stored by Git (not a copy of every version)
Push
Do this whenever the file(s) is ready to be
shared with your team, or ready for inclusion in
the latest build
Branching
Do this: Always when you are changing the site
Git Flow Technique
Versioning
Branches or tagging
Different customer customizations
Hot fixes
Reverting
Merging
Automatic merges if only different line have been changed
Merge conflicts if two people/branches have changed the same code lines
“Commit early, commit often”
Git Best practices
Make a branch called “Master” for what the Production server should look like.
Don't actually write code in this branch.
Write in other branches, then merge them into Master.
Anytime you “pull from Master”, you get an exact copy of what's on the Live server.
Make a branch called “QA”. As bugs are fixed, merge them into QA.
When everything in QA has been tested and debugged, merge it into “master”.
Don't be afraid to make “temporary branches” to try out new ideas. No harm in making and deleting new branches.
More Git Resources
Why are you proud to use CF?
WWIT for you to make CF more alive this year?
What are you looking forward to at CFCAMP?
Git Source Control: for the Rest of Us
What about those designers/JS/CSS folks that WEREN'T using Subversion, and don't CARE about how under the hood Git uses a different type of pointer file storage thing, blah blah blah? There's a whole new wave of developers/designers that could stand to have an intro to Git that matches their workflow more concisely.
Target Audience: People that want to learn a) what source control is, and when/why I should use it, b) people that don't drop down to a command-line interface for such tasks, c) everyone that's been snickered at when asking how to use a GUI tool to start learning Git, instead of those strange command-line instructions.
Assumed knowledge: A familiarity with asset files and the idea that "I need to make backups of these and share them with my team in an organized way". For this presentation, I'm making no assumptions about any prior knowledge or use of a source control system.
Objective of the topic: So far all the "Intro to Git" presentations I've seen have covered the same points, and all assumed the user does source control management via the command line. For a lot of people, that's simply not the case. For example, front-end developers that came from a Photoshop background and are now doing more HTML/CSS work. Let's get these people up to speed on how to use source control in way that makes sense to them!
Mentioned in this episode
Git
Git was created by Linus Torvalds in 2005 for development of the Linux kernel
Git is a distributed version control systems, and unlike most client–server systems, every Git directory on every computer is a full-fledged repository with complete history and full version tracking abilities, independent of network access or a central server.
Git servers
GitHub
Bitbucket
Unfuddle
BeanStalk
Git clients
Tower
GitBox
SourceTree
SmartGit
TortoiseGit
Git Flow Technique
Alternatives to Git
Subversion
CVS
Team Foundation Server
Visual SourceSafe
PerfForce
Mercurial
Git Resources
Pro Git Book (free)
Tim Cunningham's Git presos and blog entries
And on YouTube
CF Hour Podcast, episode 118
Peter Bell's Git courses
Podcast CF Continuous Integration Plumbing with Bitbucket Pipelines with Guust Nieuwenhuis
Podcast Gitlab server Deep Dive with Continuous Integration with George Murphy
Sublime text editor
Stack Overflow
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):
random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
"global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
"g*dd*mn idiotic truckload of sh*t": when it breaks
Listen to the Audio
Bio
Nolan Erck
Nolan Erck is the Chief consultant at South of Shasta. Nolan has been developing software for 19 years. Starting in the video game industry working on titles for Maxis and LucasArts, then advancing to web development in 1999, his list of credits includes Grim Fandango, StarWars Rogue Squadron, SimPark, SimSafari as well as high-traffic websites for clients. Nolan manages the SacInteractive User Group, teaches classes on aspects of software development, and regularly gives presentations at conferences and user groups across the country.
Links
Git Source Control for the Rest of Us Presentation
Slide Deck
Interview transcript:
Michael: Welcome back to the show, I'm here with Nolan Erick and we're going to be looking at Git, and why every ColdFusion developer should be using it, and we'll look at how you can get started and some best practices. So we'll look at what source control is? Because Git is source control and why you shouldn't be using homemade source control. We know the people who make back files and zipped their files and all kinds of other things like that. Am going to explaining why that is a bad idea for security and other issues. Then we're going to have a look at what Git is? And what will different Server client options and some of the commands and some best practices you can use with Git source control for cold fusion? So welcome Nolan.
Nolan: Hi Mike. Thank you for having me.
Michael: And for those of you who don't know Nolan he is the chief ColdFusion guru of [unintelligible, 00:53] productions and he is also the world's biggest music collector in the ColdFusion community, I saw a picture of his album collection, it was like wow! To hear with albums must be thousands of CD's and even [unintelligible, 01:10]. Pretty amazing just in case you were a music collector as well. So why don't we just start off with these three people in the room, or listening to this who don't know what source control is? What is it and why should everyone be using it?
Nolan: So source control is… it's sort of like a librarian for the source code in your app. When you check a book out of the library, the library marks down who has the book?
Read more
And to continue learning how to make your ColdFusion apps more modern and alive, I encourage you to download our free ColdFusion Alive Best Practices Checklist.Because… perhaps you are responsible for a mission-critical or revenue-generating CF application that you don’t trust 100%, where implementing new features is a painful ad-hoc process with slow turnaround even for simple requests.What if you have no contingency plan for a sudden developer departure or a server outage? Perhaps every time a new freelancer works on your site, something breaks. Or your application availability, security, and reliability are poor.And if you are depending on ColdFusion for your job, then you can’t afford to let your CF development methods die on the vine.You’re making a high-stakes bet that everything is going to be OK using the same old app creation ways in that one language — forever.All it would take is for your fellow CF developer to quit or for your CIO to decide to leave the (falsely) perceived sinking ship of CFML and you could lose everything—your project, your hard-won CF skills, and possibly even your job.Luckily, there are a number of simple, logical steps you can take now to protect yourself from these obvious risks.No Brainer ColdFusion Best Practices to Ensure You Thrive No Matter What Happens NextColdFusion Alive Best Practices ChecklistModern ColdFusion development best practices that reduce stress,
