MrQwest

Why I'm Learning GIT

It was a few years ago now that I started to see & hear people talking version control. I’m sure it’s been around a lot longer than a few years, but it’s only become obvious to me in the last 3 or 4 years. I kept hearing about SCM apps like Versions for OSX and TortoiseSVN for Windows.

It sounded like a good idea – keep control of the changes you make to the code you produce. Create a branch to test new features before merging it all back into the Master so you never really screw up your work.

But I am just a single front-end designer

I used to tell myself that all the time. It’s just me & my laptop. I don’t need version control as I’m always using the latest version to edit etc. etc.

I then started to notice the odd project_v2 and index_v7.html files pop up on my hard disk. Hmmm, but I’m just a single front-end desinger. It’s good to look back and visually see what files I have.

But all the cool kids where using SVN and then GIT as that became more widespread.

So I had intended on learning it. I may not use it but it’s another skill under the belt.

Fast forward to January 2011. I’m working hard on my re-design to get it live before New Adventures Conf even though it was essentially done, I wanted to make sure it was perfect so I didn’t launch before the conference but shortly after.

I continued to tweak the CSS from time to time after launch by logging into my FTP and doing it direct on the server. Making the odd change here, adding a transition there and tweaking the colour on that page. That sort of thing.

And then 2 weeks ago, I decided to re-do my portfolio. I opened Coda, made some changes to the CSS file on my HD and uploaded it to my server (overwriting the one already there).

Can you see what I did? The weeks of tweaks I had done previously where all live on the server copy of the style sheet, not on my machine.

So yes, several weeks work of fine tuning lost.

And that folks, is why I’m learning GIT. I’ve armed myself with several links from around the internet to help me get up to speed. I’ve installed GIT on my machine at home. I’ve started $ git commit’ing everything I do and $ git add .’ing everything I create.

I’m not wasting time like that again.

I’ve added some links to the References on the left and I’ll continue to add some more resources as I continue learning this master art. I may even write my own introduction in a couple of weeks.


Links of Reference:

Getting Started With GIT | Graham Smith
GIT Ref
A Successful GIT Branching Model
GITHub
GIT Immersion
OS X Terminal Commands
How do I clone remote branches with GIT


Why not join the discussion?

  1. Shane Griffiths | Mar 3, 12:34 PM | Permalink

    Same here buddy !

    Have you thought about using apps like tower ?

    Heard it makes things a little easier. I have setup an account on beanstalkapp thinking that I can figure out a more professional method of deploying new code to the production server. Surely the pro’s don’t open up transmit and drag their new code over the existing code ?

    My guess is that the code is pushed from local to a central repository somewhere (could be local I suppose) then use some kind of method that then pushes the latest version to your prod server ?

    This is a process that has annoyed me for a while. Perhaps it would make a great blog post. “Using GIT in real life – How to deploy to your server using beanstalk” etc etc

  2. MrQwest | Mar 3, 02:39 PM | Permalink

    Shane, I’ve not used apps like Tower although it does look good and I wouldn’t mind a swish looking interface for GIT.

    I’ve not given BeanStalk a go either. Must look into that a bit more too.

    You’ve got me thinking now, just how do you deploy code to the server?

  3. Colin Cook | Mar 3, 06:34 PM | Permalink

    Interesting post!

    Coming from the “programmer” front, I was hoping my technical skills would allow me to understand Git a bit quicker than most. It’s still quite a challenge to me, however.

    I think I understand most of the concepts now— I think understanding key concepts, such as the ‘working directory’, and ‘the staging area’. Why add to the staging area? Can I switch branches and add different files? Why would/wouldn’t I want to do that? When do I pull/push to a remote server?

    I would have an educated guess on the answer of those questions, but I don’t have full confidence just yet.

    I think a difficult part for me will be viewing a timeline of commits and understanding what the fruit is going on. If I ever get involved in a Git project with many people, how can I navigate and know what branch is going in what direction?

    Be curious to see your next Git post!

  4. MrQwest | Mar 4, 08:47 AM | Permalink

    Cheers Colin, and it surprises me to hear that even you are finding GIT a challenge–you’re one of the cleverest guys I know!

    It’s like anything really, you need to understand the fundamentals to be able to grasp how to use it properly. I too am starting to understand bits & pieces of GIT.

    I get the idea behind the staging area, and working directory. I know why it needs to go into the staging area, and how to commit it to the branch. It’s the push / pulling that I dont understand, and to echo Shane’s comments above, how do you deploy it to a live server?

    And that’s an interesting point you’ve raised. If you’re involved on a git project with 10 other developers, do you create your own branch – do your thing and then merge it back? How do you know you’re working on the latest files… I guess that’s the beauty of GIT or SCM in general, regardless of whether you’re working on the latest files or not, you can merge your changes into the latest files at any point can’t you?

  5. Colin Cook | Mar 4, 05:53 PM | Permalink

    I think as far as creating branches are concerned, so long as you’ve checked into the branch you want to branch, it’s as easy as “git branch cheesecake”. I quite like the idea of small-scale branching; spending a few days on one feature, checking into another branch and trying another feature, perhaps merging it back to master and resolving any conflicts (which apparently, a major strength with Git is the way it knows how to merge text files together).

    I found this web link a few months ago, with a few interesting images: http://nvie.com/posts/a-successful-git-branching-model/

    I like how master is the ‘live’ product, and how they always have a master and ‘development’ branch in parallel. I also like the way it handles urgent ‘hotfixes’. I imagine a team would sit down and establish the model before doing anything else…

    …but then, if I was to join someone elses Git project, is it possbile to see with ease how they’ve modelled it?

    That’s it, i’m buying a cheesecake.

    As for the pull/push thing, I BELIEVE that’s why services such as Github exist— it’s an external holding area for a repository, you
    1) Clone a Github repo to your local machine
    2) Edit your local copy, commit changes in the normal way
    3) You frequently (manually) pull from Github to ensure you have the latest copies (and let Git merge your changes with the new ones from Github)
    4) Once you’re happy with your code to share, you “push” to Github for the project owner to merge and resolve conflicts. Eventually to be authorised, so others “pull” your changes.

    I may be completely and utterly wrong.

Textile help

You must preview your comment before submitting.

Search

Hire Me