Blog Archives - 18 Record(s)

Year: '2013' - Month: '11'

November 2013

Gavin Pickin

Team Coldbox wants your Input - Pre-Conference Survey

Chit Chat, Online Interactive Learning

Ortus Solutions and Team Coldbox asked for your input today, on their Pre-Conference Survey. Ortus Solutions and Team Coldbox are asking for feedback for a 1 day Conference they are planning, in addition to the full 1 Week Free Online Developer Conference (Coldbox Developer Week CBDW Links below) provided the last 2 years, which is a great free resource by the way. 

Here is your chance to give Ortus your opinions and help decide on the content, and they even have a question about Pricing... so if this is something you might be interested in attending, you really should spare a minute, and cast your votes.

Here is the blurb on the Survey Form

Hi everybody,

We are planning to do a One Day Conference with around 14 labs and sessions focused on all Ortus Products like ColdBox, ContentBox, WireBox, LogBox, CFCouchbase, and much more, and we would like to hear what topics are of interest to you! We have created a tiny survey to gather information from who's important: YOU!

Your wants/desires/concerns/comments are greatly appreciated and will guide us to providing the most effective and valuable conference sessions for everyone.

THIS WILL ONLY TAKE A MINUTE! Thanks in advance for your time!

Do your part, and fill in this quick Pre-Conference Survey today.

Free Online Conference Resources - Coldbox Developer Week

Other Coldbox Links


November 2013

Gavin Pickin

Free Sencha Touch and Ext JS 4 Training Tutorial - Free Online Training

Online Interactive Learning

Technology is always changing, and we have to do our best to keep up with the times... so as I find good online learning resources, I am going to share them here. Not every online tutorial or course is a good one, and free is even harder to find. I have not completed this one yet, but from what I have completed looked good, I have heard great things about the company, Fig Leaf Software, the Founder and President, Steve Drucker, presented at Adobe Coldfusion Summit in Las Vegas just a month ago on jQuery Mobile, so with that being said, here is a resource that might be useful for you. 

Fig Leaf Software is offering a free tutorial / online training, called Teach yourself Sencha in a Day. 
Sencha Touch is one of the leading Mobile Frameworks, with Ext JS 4 a full featured desktop Framework. Sencha has a full range of tools to support all levels of developers... including a GUI IDE, Mobile and Desktop Packaging tools, and much more.

A little about Fig Leaf Software (from their website)

Fig Leaf Software is an award-winning team of imaginative designers, innovative developers, approachable instructors, and insightful strategists.

For over 20 years, we've helped a diverse range of clients with needs across the entire spectrum of web-related services, including design, marketing and content strategies, custom software development, product licensing and personalized training.

Located in the heart of Washington, DC, we're a Veteran-Owned Small Business with a keen ability to understand your needs, a broad array of strategic Partners, and a talented team eager to make your latest web initiative a resounding success.

Fig Leaf maintains close partnerships with Sencha, Adobe, Google, Acquia, Ektron, and other thought-leaders in web application development and web content management.
Check our our professional services offerings at

If you're looking at JS Frameworks, or Mobile Frameworks, this free Online Tutorial might be a great way to see if Sencha is for you.

Start today.

November 2013

Gavin Pickin

Git for Dummies - Pushing Code from Dev to Production with Git

Source Control

Thank you for reading along with my Git for Dummies series. We've covered a lot so far, and we're starting to use Git now, and as we continue in this series, we'll start to see a few more day to day tasks, and we'll introduce some of the bigger concepts as we face a few hurdles. Thankfully, Git makes these hurdles into more of a speed bump, and you'll see a good example today.

So far we have covered Why you should use Source Control, Not Using Source Control, amazingly you're not aloneInstalling Git on WindowsInstalling Git on Mac OSXInstalling Git on LinuxYour First RepoSetting up your first Remote Repo on BitbucketCreating your SSH Keys for Bitbucket, How to set your Default Name and Email in Git, Converting a Project into a Git Repo, today, Pushing Code from Dev to Production with Git.

Note - I'm sorry for the slight down period, busy life, busy work, but everyone knows how that goes, we'll try and keep them flowing now.

I am assuming no one is developing on Production (much) these days... it seems to be running joke on Twitter it must be a best practice if Adobe has RDS... but if you are editing live on Production... I hope using Git will help take out some of the reasons you might be doing so, because Git can make it so much easier, to deploy lots of code from a Development Server, to Production... and today we'll look at that.

So, I assume you have the following for todays walkthrough.

  • A Git repo, ours is setup on Bit Bucket, as described in an earlier session
  • A Development Server with a Clone of the Bit Bucket Repo
  • A Production Server with a Clone of the Bit Bucket Repo

Now, we're not going to cover Branches at this time, so we're going to assume we have just 1 branch, the master branch, on both servers. This is not ideal for major feature upgrades, but for small ongoing maintenance to a website project / application, this usually will suffice.

So what we want to do in this situation is take New Code, Version 3 in this example, from the Dev server, and deploy it to the production server, which is running Version 2 (over simplified to make it easier to follow). So, to start, we have 3 repos... 

  • Bit Bucket Repo - Version 2
  • Production Server - Version 2
  • Dev Server - Version 3 

So, the process would be, push from Dev to Bit Bucket Repo... and then Pull from Bit Bucket Repo to Production Server... and we are done.

Let me throw a curve ball at you... what if one of your devs had made a change? RDS, FTP, or maybe your application allowed the Users to modify files, upload content etc, and you wanted this to be as similar as possible on dev and production? A lot of my applications have this curve ball, so I'm going to show you the process I use, just to make sure that in a case like we have, where Production is really Version 2.1, we dont have any possible code clashes... especially in production.

Code Clash? Well, thats the name I've been using, but basically, when you have 2 files, Git nicely tries to merge any changes, and if you have edited them in such a way that Git cannot automatically merge them... you will get a Merge Conflict (Code Clash in my strange mind) and you will have to manually merge the file... and Git does this by creating a DIFF file, which includes both versions of the file, in the file... and you manually fix this. Long story short, a DIFF file in production leaves your code broken, and is not ideal, so you want to make sure these Code Clashes, or Merge Conflicts always happen on the Dev side... not the Production side. We'll be going into this more later, but for now, we are going to do things a particular way, to avoid issues in Production.

Ok, so now we have this situation

  • Bit Bucket Repo - Version 2
  • Production Server - Version 2.1
  • Dev Server - Version 3 (not including 2.1 update)

Since we do not want any Code Clashes on the Production Side, we want to make sure when we Pull code from the Repo to Production, it has no possible conflicts... and the way to do that, is make sure there are no new changes on Production. 
To achieve this, we are going to push all of Productions changes to the Bit Bucket Repo. 

First we do a git status to see what files have changed. This case, we see there is an update to the dsp_content_footer.cfm page. So we use Git add filename to add the file, we see its ready to commit, so we commit the file.

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#	modified:   _gmods/dsp_content_footer.cfm

$ git add _gmods/dsp_content_footer.cfm 
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#	modified:   _gmods/dsp_content_footer.cfm

$ git commit -m "Updated Content Footer"

After we commit the file, we need to Push the file to the Bit Bucket Remote Depo... and now once this is complete, Production and Bit Bucket Remote Repo are Version 2.1 and Dev is 3

$ git push
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 569 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
   c600e77..07a5ac1  master -> master

Now, this is where the code clash could happen. Dev has gone from Version 2 to Version 3 directly, while Production went from 2 to 2.1... so Dev never got the .1 update. So now, we need to Pull the .1 update from the Git Remote Repo on Bit Bucket. 

Remember, Git is smart, so instead of overwriting Dev with Productions changes (like FTP would if you were working with older tools), Git will see that there is a file conflict, and try and resolve it... lets look at how that works.

$ git pull
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
   c600e77..07a5ac1  master     -> origin/master
Merge made by recursive.

So we perform a git pull (we do not state the location, as we only have 1 remote, and 1 branch, so git instantly knows what to pull... if you have multiple remotes and or branches, you would need to be more specific)... and all looks good, but wait, that final line... what does it say?

Merge made by recursive.

That means Git noticed that there was a possible conflict, but it was one that it could figure out automatically. If this was not the case, a code clash would have temporarily corrupted that file by making it into a DIFF file, and having a copy of both files in the one file. The conflict would not have been as damaging though, because we had the merge on the Dev side, and it could be quickly resolved, and no live customers / clients / visitors never saw a problem on production.

So now, we have the following status of our repos.

  • Bit Bucket Repo - Version 2.1
  • Production Server - Version 2.1
  • Dev Server - Version 3.0 (including the .1 update)

So now we have merged our sets of changes, now we are finally ready to Push from Dev to Remote, and then Pull from Production, like we said initially. This practice of checking Production first doesn't apply for all situations, but because of our CMS and how we want to include Website Resources in our Repos, we have to follow these preliminary steps before pushing from Dev to Production.

Ok, so now, lets make sure our changes have been tracked, staged, and committed (not shown in this case - view other entries for how to track stage and commit changed)... then we can do our Git Push.

$ git push
Counting objects: 16, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 896 bytes, done.
Total 9 (delta 5), reused 0 (delta 0)
   07a5ac1..ac30df9  master -> master

Now, our Repos look like this.

  • Bit Bucket Repo - Version 3.0 including 2.1 update
  • Production Server - Version 2.1
  • Dev Server - Version 3.0 including 2.1 update

Now, the Dev server is merged and up to date, and so is our Bit Bucket Repo, so we can just pull the changed on Production from the Remote Bit Bucket Repo.

$ git pull
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 9 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (9/9), done.
   07a5ac1..ac30df9  master     -> origin/master
Updating 07a5ac1..ac30df9
 _gmods/pdfs/.gitignore  |    5 +++++
 errors/dumps/.gitignore |    6 ++++++
 2 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 _gmods/pdfs/.gitignore
 create mode 100644 errors/dumps/.gitignore

The git pull was successful... and you can see what the pull did. Obviously in this case, my Version 3 upgrade was a couple of gitignore files. Good timing, as those are coming up soon in the Git for Dummies series, as we start to use Git more, we want to customize git options, so we know what files we want to track, what files we do not want to track, and learn a few more tricks out of the very cool and powerful Git Magic Trick bag.

Check back soon... thanks for reading.


November 2013

Gavin Pickin

Git for Dummies - Converting a Project into a Git Repo

Source Control

Thank you for reading along with my Git for Dummies series. It can be a daunting task, and this series tries to show you step by step all the little processes you will come across as you start using Git. The best part about it, I'm not a Git expert, I'm fairly new to it, and as I help people I know get better, I'm sharing the knowledge with you. 

So far we have covered Why you should use Source Control, Not Using Source Control, amazingly you're not alone, Installing Git on Windows, Installing Git on Mac OSX, Installing Git on Linux, Your First RepoSetting up your first Remote Repo on BitbucketCreating your SSH Keys for Bitbucket, and today, Converting a Project into a Git Repo.

Being a developer, you have loads of projects sitting around, small ones, big ones, but we've only showed you how to start a repo from scratch, well, that doesn't help you with all the existing projects, so we'll walk through how to make an existing project into a repo, and how to store it on Bitbucket. If you have been following along, a lot of these steps will be the same as when we created a repo from scratch. Its actually very similar.

So first, lets go to BitBucket, and add a repo. Click on the Create button, and you'll see the form below.


Ok, so we fill in the form, adding a useful name for easy reference... note if its private or not (if its public, we use GitHub due to the open source social atmosphere, although Bitbucket can be used for Public repos to), select our options, language, and click Create Repository when we're all set.


Once we do that... we see one of Bitbucket's helper pages. Every time you create a repo, they have they little helper pages to help you through the initial startup, and they're a nice way to make sure you know what you're doing. So you can select I'm starting from scratch (like a previous entry), or I have an existing project to push up, thats what we're doing, so lets Virtually Click that.


So now we see this page. If you are a true beginner, you might not see something is missing here.
We said we had an existing Project, but not an existing repository, so the instructions below are correct, but if you jump straight into your terminal / bash, and do this, you'll get an interesting error, I think. Lets try it and see.


$ git remote add origin ssh://
fatal: Not a git repository (or any of the parent directories): .git

As I suspected... you cannot do a git remote add origin command, on a directory which is a Project yes, but an existing repo, no.
So, lets click back on the Start from Scratch slide, and see what we can do.

Ok, now, since we have an existing project, we'll skip the first line, making the directory... so lets just cd to the path, and then we'll do a git init.


Now below you can see the result or my bad first command, and then I do a git init, and now the repo is initialized.


So now we can go back to the previous slide, where we have a Project, and it is now a Repo, and now we can continue.


We have a repo, so we can add the git remote add origin, so lets do that.

$ git remote add origin ssh://

Ok, now we have done that, the next step says, git push -u origin --all and --tags. 
Thinking about this, we initialized a repo, but we haven't got anything to push yet... so what does this do.


Why did that happen? We initialized the Local Git Repo... but you didn't add anything to it. Git only pushes files you tell it to watch. We made a repo, now we have to add the files to the repo. If we were starting from scratch, or we just wanted to add a readme, we could follow the instructions below, but lets add all of the files from our project into the repo.


Now, this is the only real difference between a start from Scratch and Existing project... we need to do a simple command.

$ git add .
$ git commit -m "Added Existing Project Files"

What line 1 does, is recursively add all files to gits list of tracked files, . is a wildcard.
You can add them individually like the readme in the above slide instructions, but with an existing project, that is not realistic.

The second line, we commit the tracked files, into a commit point on the timeline. Now, we'll see some output like the following screenshots.

Lots and lots more files and then


Now, once the files are committed to the local repo, we can use git push to push them to the origin, and we want them in the master branch of the origin... so we use the following command.

$ git push -u origin master


The next step in the slide walkthrough is to invite your friends, and or colleagues.


And ta-da, you're all set. Now when you go to the Repo Page, instead of these helper slides, you'll see the actual commit history.


Now, everytime you go to the Repo Overview, you'll see this.


Now, that is a long detailed walkthrough, for those wanting to know what we actually did, he is the short version, for future use.

$ cd /path/to/your/project/
$ git init
$ git remote add origin ssh://
$ git add .
$ git commit -m "Added Existing Project Files"
$ git push -u origin master

If this is the first time you have committed to any project on this machine, you might have to set a couple of global variables if Git cannot determine them on its own... your name, and email address... you can follow the commands you see in git, or you can go here for a simple walkthrough to add Global or Local settings for you Name and Email Address in Git.

Text we'll learn about Pushing and Pulling from Local to Remote, and from Remote to Dev, and maybe even Remote to Production.

November 2013

Gavin Pickin

Git for Dummies - How to set your Name and Email Address in Git

Source Control

We have walked through a lot of different tasks in this Git for Dummies series so far, but there is something I forgot to mention when I wrote the first few. I will go back and update Installing Git on WindowsInstalling Git on Mac OSXInstalling Git on Linux,  and Your First Repo, but I wanted to add a separate entry, for those who have already read those, and might not go back and see the update.

Depending on how your machine is setup, Git can sometimes guess what your Name, and Email Address are, and will use those when storing your commit, so you have more meaningful tracking information. My machines are either setup for auto-detection, or I had set that global setting in git, so I completely missed that step in the walk throughs, until someone reminded me, so here I am, coming back to fill in the gap.

If you try and make a commit... and git cannot auto-detect that information, you will see something like this.

Git is nice enough to give you the issue, and the resolution, so you probably do not need this walkthrough, but still, this series is for Dummies, and sometimes its better to have a walkthrough to follow, than some seemingly good on screen advice... but in this case... its good advice.

So we'll run the commands below

$ git config --global ""
$ git config --global "Gavin Pickin"

You can see there is no output, therefore you assume it worked.

Note, as stated in the helpful output git gives you when it cannot determine your identity... you can globally set your Name and Email address, as I am showing you, or you can use the following commands to just set the Name and Email address for that given repo.

$ git config ""
$ git config "Gavin Pickin"

So, now we can try the commit again, and see if it works.

$ git commit -m "Initial Commit from Production"

And you see the commit does it's thing, creating mode this and that... no problem.

Sorry for missing this simple step, I'll add it to the old walkthroughs just in case.
Hope it helps on your Git Journey.

Check back soon for the next entry in our Git for Dummies Series.

November 2013

Gavin Pickin

Online Interactive Learning - LearnStreet - Javascript Python and Ruby

Online Interactive Learning

In our field, we are on the constant slide down the technology hill, and we have to fight, climb, run, jump, do anything we can to try and stay on top. Luckily, as technology advances, so do the awesome online training tools available, and surprisingly, a lot of them are FREE.

I thought I'd look at a few of them, it seems like every week there is a new one, but as I hear of them, I want to evaluate them, see which ones are good, and why, and share the knowledge with you. 

Last week on Twitter, I heard about NodeSchool again, Ray Camden is always talking about them, and for good reason, but then I heard of one that hadn't crossed my radar before then. Carol Hamilton was talking about one of her sons, stealing her laptop to get back to If its that appealing to an eleven year old... maybe I should have a look... so thats what I did.

As you can see from the screenshot above... LearnStreet is for students, and teachers. Its an interesting idea, trying to provide the tools, and programs, for free, to get programming into our schools, and provide a quality experience to ensure its a big part of tomorrows developers.

I went through the Javascript course, as a good test of quality, duration, and challenge, and of course, to see if I remember the basics of Javascript... enough to pass the course, without requiring the hints. This course was comprised of 7 lessons, each with an Overview of the Lesson, and a series of exercises. Each exercise references videos if you need help, and hints to help you if you're stuck. You can easily go back and revisit past course lessons, and there is a glossary as well. 

The best part of these courses are, the interactive and quite handy Console... that as you progress... you are required to code and test your code, to see if you're passed the exercise, and get feedback as you go. I love this interactive learning that forces you to actually code as you go... this is why I'm trying to spread the knowledge about Coldfusion Koans and how Koans can help you and your development team... thats why I proposed the talk for cfObjective

I found the course was a solid beginner level course, and although the concepts were not too advanced... it still made you think with one or two of the exercises. The lessons were short, and sweet, and to the point, great for young programmers in the making, and a lot of us multi-tasking wanna learn everything types, were we can only spend a few minutes on each of the 20 things on our todo list at one time.

The course was pretty nice, but one of the nicer features of LearnStreet was the Projects section. which is a series of projects / challenges, for each of the language offering, from Beginner, Intermediate to Advanced, comprising of Tools, Games, and Algorithms. One of the first ones recommended when I finished the Javascript Course was Snakes and Ladders. You do not have to create the whole game, the UI and most of the code is done for you, and hidden, but you are given some specifications, and guidance, to complete the game, and when you're done, you can play it. Again, for each piece of the project, there are hints, from simple, medium, to give you the answer, but you can do your best to complete it, and worse case, you can see how its supposed to be done.

Its a great looking tool, from the small amount I've seen, and by the sounds of the teaching section, I can only imagine this tool gets better and better with time. The company is a small company, with the right reasons behind their product, and I think in time, this could be a really great resource, for Teachers, Students, and developers alike. 

I like it so much, I might even have to try the Python course out.

PS: I have been looking at LearnCFInAWeek, NodeSchool, TutsPlus (which the free courses are kind of hidden and pretty cool - more to come later on those), CodeSchool with their free day passes floating around on twitter, a new Coldfusion Community project started by Abram Try CF available at, and there are lots more of courses around.
So, if you use an online interactive learning site, leave some feedback.

  • What is it? 
  • Is it free, per course, or subscription?
  • What topics?
  • What type of course is it, Videos, Text, Interactive Consoles etc. 

November 2013

Gavin Pickin

cfObjective 2014 - Make your Vote Count - NOW!


cfObjective, a great Coldfusion focused conference, with a lot of other great technology topics to complement ColdFusion, has only a couple more days left for you to get your vote in on what topics you would/might want to see at cfObjective 2014. Voting ends 11/11/2013

The Content Advisory Board dedicates a lot of time and energy to make sure cfObjective has the best content possible, by having open call for speakers (now closed) and then public voting... using Trello - the link is here
The CAB states the voting is an important part of their selection process, but it is not the be all and end all. 

Last year was my first time there, and although I didn't have any input on the conference, it was awesome.
This year, I made the most of it, I submitted 3 topics, and have voted on an array of topics... and tried to reach out to every I know to vote too. 

Please, do your civil duty, and help make cfObjective better than ever, whether you intend to attend or not.

Read more about my topics in previous entries here.

November 2013

Gavin Pickin

Git for Dummies - Creating your SSH Keys for Bit Bucket

Source Control

Many Git Servers communicate using SSH, and to authenticate, you should use SSH Keys. You can setup multiple keys, but that goes beyond a Dummies setup… so we'll setup a general Public / Private SSH Key Pair.  If you don't have a Bit Bucket account, make sure you go through this post. If you need to install Git on Windows, Mac OSX and Linux, visit some of my older posts.

To see a list of keys you currently have available, you change directory to .ssh and list the contents

$ cd ~/.ssh
$ ls

You might see a couple of files, but if you're new to SSH, you'll probably see the following, i.e.- just known_hosts

Now, we want to generate keys, so we enter

$ ssh-keygen

It will start generating the keys. First, it will prompt you for a name for your key, the default is "id_rsa", You can accept the default.
Next, it asks you for a password. If you are concerned about security on this machine, you can enter a password, or you can leave it blank, which is ideal for automation scripts, or for dummies and lazy people, so that's what I'll do.

Zip, zap, zoom, away it goes, and ta-da, you have generated your keys.

Once you have generated your keys, to use your private key, you need to make your public key, public… so if you don't have a Bit Bucket account, make sure you go through this post.

Once you login, you want to click on the Avatar in the far right corner, and click on Manage Account.

Once your Manage Account screen comes up, you need to look for SSH Keys on the left hand side. This is where you store your public key, so Bit Bucket can authenticate your machine, and let the machine with the right keys access repos on this account.

The SSH Keys Page lists all of your SSH keys asociated with this account... listed from newest first to oldest. This screenshot just shows the most recent key in my list.

Click Add Key to add the Key for your new Machine.
Give the Key a meaningful Label. Copy the contents of your file... and paste it into the Key field like below.

Click Add Key, and then you will see it is successfully listed in your SSH Key list.

Now each time we communicate from this machine, with a Bit Bucket Repo, we'll match our Private Key with Bit Buckets Public key for our account, and we'll be allowed access to any Repo our Bit Bucket User has access to.

So lets go back to the command line, and try it out.

$ git push -u origin --all

Sorry for the continuity here, its another repo, but showing how a successful push looks.

As you can see below, Git knows we want to push all of the branches, and we trust the server, and Bit Bucket uses the keys to authenticate us, and the push is successful.

Now we have keys setup, and we pushed our first repos... you probably are thinking to yourself, I don't want to start from scratch for every repo, what if I have websites and projects that already exist?
No problem, its not much different than starting from scratch, check back for that entry coming soon.

November 2013

Gavin Pickin

Git for Dummies - Setting Up your Remote Repo on Bit Bucket

Source Control

Git is a distributed system, so you have "local" repos on you and your developers machines, and then (usually) a remote repo.
In our last walkthrough, we started by creating the "local" repo on your machine... now we need to setup the remote repo, in this example, we're going to use Bit Bucket, because you can have unlimited free private repos for individuals, and small teams, and very affordable prices for bigger teams.

So, first, we need to go to Bit Bucket, and signup an account, if you dont already have one.
Go to and filled out your User Name, Email, Password and click the button "Sign Up for Free"

You might have to prove you're not a robot, and then you'll be prompted for your Name, Location, Website, etc, you can fill that out, or Skip to the next step.

Once you are done with that, you'll be at your dashboard, and you'll be prompted to Import a Repo or Create your First Repo.

Click "Create your First Repository" and lets get going.

  • Give your a repo a meaningful name... and a description if you want to make it clear the purpose of the repo.
  • If you want to open this up to the public, you can uncheck the "This is a private repository" checkbox. If you want a public or open source repo, you can always use GitHub, but Bit Bucket is great for free Private repos, but if you want to keep your repos together, you could have your public repos here too.
  • You can select your Repo type, Git or Mercurial. Bit Bucket was initially only Mercurial, but Git is the popular Source Control system, so they added support for Git too.
  • If you want Issue Tracking and Wiki features for your repo, you can select these too, and a Language as well. Being a Coldfusion developer, its nice to be able to choose my language of choice.

As you can see, there are some helpful resources on the right hand side, Bit Bucket 101, and working in a Team... so you are only a click away from help if you need it. So far, I really like the Bit Bucket help, it has helped me as I learned the process... good documentation is always a plus when you're picking up new technologies.

Once you are done, click Create repository, then Bit Bucket continues to walk you through the process to add code to your repo.

First, you are select I'm starting from Scratch, or I have an existing project to push up.
In this case, we're going to start from scratch, our first repo we created in the last walkthrough was a simple repo from scratch, so lets walk through those steps.

As you can see, it gives you step by step instructions on how to make a directory, initialize git for that directory, and then the next step, which is new for us... adding the remote origin location. This tells our local git repo, where the remote server is, and how to communicate with it. you can copy that command (this will work on Windows in the Git Bash and at the command line on *nix systems), and run it to add to your repo.

Lets jump into the command line, and add our remote repo... and after we add them, we'll run another command to see what our changes set.

$ git remote add origin ssh://
$ git remote -v

Now, our Remote Repo is added, we can go to the next slide in Bit Bucket, and see what the next step is.
The next step is to make changes and push. We jumped the gun and did 3 of the 4 steps in the last entry, but its a nice reminder, for the next time you start a new repo.

EDIT - If this is the first time you have committed to any project on this machine, you might have to set a couple of global variables if Git cannot determine them on its own... your name, and email address... you can follow the commands you see in git, or you can go here for a simple walkthrough to add Global or Local settings for you Name and Email Address in Git.

The only step we didn't complete, was pushing our changes from our "local" repo to our "remote" repo.
Lets try that... but we'll try it without the -u origin master and see what it says

$ git push

First, you'll see that the authenticity of host can't be established. The first time you talk to a new SSH server, you have to decide if you want to trust the server or not. Type "yes" and click enter and that server will be added to the list of known_hosts in your ssh folder. You wont see this again (unless you're connecting to a new server).

Then you'll see "Permission denied (publickey)"
This is because when you communicate with Bit Bucket servers, you communicate over SSH, and the server cannot tell if this machine has permission to add to your repo or not, not without a SSH public and private key. 

To push to the remote repo, we need to setup a SSH Key... so thats next.
We're almost there... creating our first local repo was easy, the remote repo was pretty easy too, but we just have to setup a few settings...the last step is SSH keys, and we'll deal with that next. Thanks for reading, check back soon for SSH Keys.

November 2013

Gavin Pickin

Git for Dummies - Your First Repo

Source Control

If you have been following along, you will have learned that the reasons you were not using Source Control (assuming you are reading this because you're not using it) were not really good reasons, and you've installed Git on Windows, Mac OSX, or Linux, and you're ready to create your first repo.

Git is a distributed system, so you have "local" repos on you and your developers machines, and then (usually) a remote repo.
We're going to start by creating the "local" repo on your machine.

Open up your Git Bash (on Windows) or Terminal (Mac) or Command Line (Linux).
These commands should be universal, because Git Bash uses Linux based commands, and Mac OSX and Linux are *Nix systems of course.

Just to make sure Git is installed, you can type

$ git version

You should see Git version (depending on your install of course). Change directory until you are in your Websites dir. On my machine, I have all my websites in /www

Now, we're going to create a "new" repo from scratch. We will create a new repo for an existing website / project next.
So I'm going to create a new directory called "MyFirstRepo" and cd into that directory

$ mkdir MyFirstRepo
$ cd MyFirstRepo

To create a repo, all we have to do is Initialize Git in the directory, and Git creates a .git folder, and starts watching this directory and subdirectories.

$ git init

And tada, you're Initialized an empty Git repository.

Now, lets create and add a "readme" file, and make our first commit.

To quickly make a "readme" file, we can use a command line shortcut

$ echo "# This is my first repo's readme file" >>

Now we have a readme file.
Is Git tracking our new file? To find out, lets check the status of our repo

$ git status

You can see the output of that command below.

The output shows us we're on the Master Branch, and we have an untracked File Git is even nice enough to show us how to add the file to the repo so Git will track it.

$ git add
$ git status

Now we have added the file, and we run git status again, and now we see no files are not tracked, and we have a new change, ready for commit.

Once we are happy with our set of changes, we need to commit our changes to our repo. Commits allow you meaningful milestones in your code, with comments, and allow you to change back and forward "versions", which relate to these Commits.

To commit this change, and make a comment with the commit, we run this command... and run a git status after to check the status of our repo

$ git commit -m "This is my first commit to the repo, just a simple README file"
$ git status

EDIT - If this is the first time you have committed to any project on this machine, you might have to set a couple of global variables if Git cannot determine them on its own... your name, and email address... you can follow the commands you see in git, or you can go here for a simple walkthrough to add Global or Local settings for you Name and Email Address in Git.

Now, our changes have been commited, and the git status shows us that our repo is clean, there are no untracked files, no files waiting to be commited.

Great, we have our first local repo built, now we just need to push our changes to our remote Git repo.
To do that, we need to setup an account with Bit Bucket, setup SSH Keys for authentication from the command line, and change the configuration for our repo, so it knows where our remote repo is... so check back for those walk through blog entries soon.

Blog Search