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
- Server
- 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.
- Make a branch called “Master” for what the Production server should look like.
- 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
- Git clients
- Git Flow Technique
- Alternatives to Git
- 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
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?
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 Next
ColdFusion Alive Best Practices Checklist
Modern ColdFusion development best practices that reduce stress, inefficiency, project lifecycle costs while simultaneously increasing project velocity and innovation.
√ Easily create a consistent server architecture across development, testing, and production
√ A modern test environment to prevent bugs from spreading
√ Automated continuous integration tools that work well with CF
√ A portable development environment baked into your codebase… for free!
Learn about these and many more strategies in our free ColdFusion Alive Best Practices Checklist.
