051 Git ColdFusion Source Control (Getting Started and Best Practices) with Nolan Erck

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.

Contents

Episode highlights:
Mentioned in this episode
Bio
Interview transcript:
Episode highlights:
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