Hi all,

Seeing that since the 1.5 release of Coda there are now many more  
people interested in version control, I thought I would give some  
pointers on how to use Git - from inside Coda - for some basic day-
today operations that a lone developer might do. This will also serve  
as a quick tour for those who think Git may be too technical, or were  
too scared to try and commit too much time to learning it.

--------------------------------------------
INSTALL GIT!
--------------------------------------------
Git installer for MacOS X 10.5 Leopard can be downloaded from here:
http://git.or.cz/

--------------------------------------------
PUTTING A PROJECT INTO VERSION CONTROL
--------------------------------------------
Now, let's say a have a folder called "my-project", which I want to  
put under version control with git.
Being the good boy that I am, I save all my projects inside my  
"Documents" folder - and that is where the "my-project" folder is.

So, let's open a terminal tab in Coda, and start typing some commands.

1) CD INTO THE PROJECT FOLDER
There are 2 basic commands you need to know, to do anything in the  
terminal:
"ls" - that is the 'list' command. Just type "ls" and hit return, and  
the terminal will list the contents of the current directory.
"cd" - that is the 'change directory' command. In order to move around  
the computer, you type "cd", a space, and then the path of the folder  
you want to go to. For instance:
- to go into a folder that is inside the current directory, just type  
"cd foldername" - where 'foldername' is the actual name of the folder.  
If the folder has spaces in its name, precede them with a backslash:  
"cd folder\ name"
- to go up one level - ie., get out of the folder you are in, and into  
its parent - type "cd .." (double dot)
- to go to your Home, type "cd ~" (that's the tilde symbol)
- to go to the topmost level of your computer (similar to selecting  
"Go->Computer" in the Finder), type "cd /" (forward slash)
All folders, applications and documents in your computer are organised  
in a hierarchy which starts with a "/".

You can also just go directly anywhere in your computer simply by  
typing the complete path of the directory. For instance, in my case,  
to go directly to my "my-project" folder, regardless of where I am, I  
can type:

"cd /users/igor/documents/my-project"

2) GIT INIT
I need to tell Git that this folder has stuff that I want to version-
control. You do this simply by telling Git to 'init' the folder.
Once you cd into the folder, just type:

"git init"

If you have Coda open and showing the "my-project" folder, you will  
see that inside that folder there is now a new sub-folder, called  
".git". That is the folder that Git will use to keep track of the  
entire history of your project.

3) CREATE .GITIGNORE
In every project, there are files that you DON'T want to put under  
version control. We can tell Git to ignore any files by creating a  
".gitignore" file in our folder, and listing these files there. In our  
case, we are going to tell Git that we don't want it to keep track of  
the Mac's ".DS_Store" files, which are created automatically by the  
system. So, create a new blank file in Coda, then name it  
".gitignore". Open it, and type:

.DS_Store

Save, and that's it. Git will now ignore any files named ".DS_Store",  
in this directory, or in any directory below it. If you have other  
files you want Git to ignore, you can list them here - one file per  
line. Each one of these lines is actually a kind of regular  
expression, so you can ask Git, for instance, to ignore all zipped  
files, by entering "*.zip" on a line.

4) ADD EVERYTHING
Now we need to tell Git that we want it to track everything in the  
folder. We do this by typing:

"git add ."   <-- note the ".", it's important! It stands for "the  
current directory".

5) COMMIT EVERYTHING
Now, before start making any changes to any files, you do an initial  
commit. The command we will use is:

"git commit -a -m "this is the initial commit"

The "-a" means "add anything that is not already being tracked". The "-
m" means "with the following message:", and that is followed by a  
short (50 chars or less) message.

--------------------------------------------
EVERDAY OPERATION
--------------------------------------------
6) WORK AND COMMIT
Now we can go, do some work, whenever we reach a major milestone - or  
just before we try something we might regret - we do another commit:

"git commit -a -m "main template now uses jquery instead of  
scriptaculous"

7) VIEW THE COMMIT LOG
Whenever you want to see a list of all your commits, you can just ask  
Git to show you the 'log':

"git log"

Note that by default, each commit has a really strange 'name', which  
is just a hashed sequence of letters and numbers.

8) ROLL BACK
Every now and then, the change you've made will be a bad one, and you  
will want to 'roll back' to a previous version - to a previous  
'commit'. First, do a 'git log', and find the name of the commit you  
wish to roll back to. Then, 'checkout' that commit - note that you  
don't have to type the FULL name of the commit, only the first few (5  
or 6) letters:

"git checkout 2fd45h"

--------------------------------------------
THAT'S IT!
--------------------------------------------
There is, of course, A LOT more you can do with Git. You can use  
'tags' to name your commits, for instance, or to create proper  
milestones for your project. Git makes it very easy to create  
'branches' - ie., alternative versions - of your project, and these  
branches can either be easily discarded, or easily merged back and  
consolidated into the project at a later stage. And, of course, using  
Git you can share your project with others, and participate in  
external development teams as well. But all that is WAY beyond the  
scope of this message! :-)

For further information, have a look at some of the online Git  
tutorials and manuals:
http://git.or.cz/#documentation

I hope this little quick tour may help some loose the fear of Git, and  
help them decide whether Git is a good alternative to their needs.

Kind Regards to all,

--
Igor Couto
Sydney, Australia

Igor,

That is really helpful!  I've been making excuses about why I didn't
have time to "get" into Git. This takes away some of the fear-of-the-
unknown factor. I'm pretty comfortable in the SVN world. How does Git
differ from SVN when used in teams?

-Andrew

On Sep 10, 8:55 pm, Igor de Oliveira Couto <i...@pixelmedia.com.au>
wrote:

Dear Andrew,

Good to see that the info was useful to somebody! :

On 10/09/2008, at 7:30 PM, Andrew Hedges wrote:

SVN is a *centralised* version control system. It works based on the  
assumption that there is a 'central repository', from where all  
members of the team checkout working copies, then check them back in  
again, once they are finished working.

GIT can be setup to work *exactly* like that, if you wish. I can be a  
fully centralised solution, for the times when you need that - and  
actually, that is quite easy to setup (easier than SVN, IMHO).  
However, where Git is basically different, is that it can also be used  
as a totally *decentralised* solution - meaning, there is no 'central  
repository'. *Every* copy of a git is a server, and every repository  
IS a 'central repository'. This concept can take a little while to get  
used to, but once you do, the freedom and flexibility it gives you is  
astounding.

Even when working alone, I've found that branching with Git is *a lot*  
easier than with SVN. I just did not do branching with SVN, unless I  
was absolutely *forced* to. In Git branches are cheap, and you find  
yourself branching out all the time - even if just to try something  
out, then destroy the branch when it doesn't work.

Git is also a lot faster than SVN - you will certainly feel it,  
specially on large projects. Some of the sites I deal with have  
thousands (literally) of graphic files. Git is almost instantaneous,  
even on the initial commit.

I'm hoping that more Coda users will catch on to the benefits of Git,  
and perhaps more will ask Panic to introduce Git support in a future  
version! :-)

Kind Regards,

--
Igor Couto
Sydney, Australia

Igor

Really helpful stuff. Much appreciated.

I'd love to see the Panic folks somehow incorporate Git as an SCM
option in Coda. It would truly rock.

Steve Collins
--
Stephen Collins
Cell +61 410 680722
Skype trib22
www.twitter.com/trib
www.linkedin.com/in/stephencollins

www.acidlabs.org

acidlabs - strategies, tools and processes to empower knowledge
workers

This email is:   [ ] bloggable   [X] ask first   [ ] private

The only problem is that, as far as I know, the GIT licence won't
allow it to be integrated in Coda's UI.

Igor, can you confirm (or not)?

On Oct 20, 7:32 am, Stephen Collins <t...@acidlabs.org> wrote:

On 20/10/2008, at 10:35 PM, StuFF mc (.com) wrote:

Git is released currently under the GNU GPL v2. This does mean, that  
if code is released that is based on it, that code should be released  
under the same license, ie., the GPL - it is what is called a  
'copyleft' license.

SVN is released currently under the Apache license - it is *not* a  
copyleft license - meaning, it can be freely included also in  
commercial projects.

This, however, is a somewhat irrelevant point. Neither the code of  
Subversion, nor the code of Git, is going to be included in Coda. The  
developers of Coda do not have to use any part of the original code of  
either application, and they do not have to base their work on that  
code, either. Building a program that *interfaces* with a GPL-licensed  
program, in my understanding, does not require that program to also be  
GPL-licensed - there are a few commercial database interface apps in  
that category that come to mind straight away.

I hope this helps clarify things.

--
Igor de Oliveira Couto
Sydney, Australia

Hi,

On Oct 21, 2008, at 2:15 AM, Igor de Oliveira Couto wrote:

I think it is a highly relevant point since it means Panic can't just  
take existing code and add it to Coda; they have to write their own  
"clean room" code or just call out to the existing Git programs on  
the user's system and then parse the results. If they use the  
existing code, Coda becomes "infected" and they have to release it  
for free, which seems somewhat unlikely.

DDA

--
DDA
  Some they do and some they don't and some you just can't tell.
     Some they will and some they won't and some it's just as well!