General, Git, Linux

Installing SmartGit 2.01 on Ubuntu Linux 10.04

SmartGit is undoubtedly my best git client both for Windows and Linux. I’ve installed it a couple of times in the last few months  already and it now is the time to stop learning how to install it again and again. Here I demonstrate how to install SmartGit 2.01 on Ubuntu 10.04

SmartGit offers many features but my best feature is the Conflict Solver. As the name implies, it helps you resolve version conflicts. Doing this without a GUI is a pain hence I treasure it. New in version 2 is a section on the bottom right of the window which shows Pushable Commits, which I think is a nice feature.

SmartGit was developed using Java so you’ll have to install Sun Java JRE. Below are full instructions on how to install both JRE and SmartGit. Installing SmartGit earlier than v2 is the same as below only that you won’t need to reinstall git.

Continue reading


Git 101 – Introduction to Git

Getting Started with Windows

Download msysgit – Essential

You should use Git-
Not tested 1.7.1 cos it’s contributors only. But

Download SmartGit – Optional but best git interface I’ve found

msysgit comes with Git, Git Bash, Git GUI and more. Git Bash is essential to getting your hands dirty. It’s a linux-based shell (will look for the appropriate term) so all your favorite shell commands are available including SSH, cp, etc.
Getting Started with Linux

SuSE Linux 11.1

# yast --install git

The above should do it. If there are issues, then you probably need to enable your online repos.

SmartGit also works on linux so you should get it


sudo apt-get -y install git-core gitosis

Git Clone
As the name implies, it creates a clone of an existing given repository.

You can try it out by launching Git Bash or your favorite linux terminal.

# git clone <repo_url>

One lovely thing about git is that the flexibility of <repo_url>. Git supports a wide range of protocols including ssh, git, http, ftp, local filesystem, etc. This means you can clone just about any git repo once you have access.

Git Init
This is for creating a new repo. e.g. on your local system.

# mkdir <my_repo>
 # cd <my_repo>
 # git init

Git Add & Commit
At this point I’m assuming you have a repo to work with and you’ve updated or added some files. So you want to update your repository with the changes you’ve made. So where do you start?

First thing you want to do is stage your changes. What staging means is telling git which files you want to commit.

# git add <file>
 # git add . (all files)
 # git add *.ctp

This is great if you want to commit just a few files. Staging is for both versioned (files already in repo) and unversioned files (files not added to repo).

After staging, you can then commit your files.

# git commit -m "<Description of Changes>"

This records your changes to your local repository. Now you can code some more.

Git Remote, Push & Pull
Now that you have committed your changes to your local repository, they won’t do you much good until you have updated your central repo/site. And thats what remote, push, pull are form.

Remotes are other copies of your repo. They may be local or online, or on your local server. Git supports more than one remote which is another lovely thing about it.

Lets assume you cloned your repo. This means you already have your remote set (its called origin). To check your remotes

# git remote -v

So how do you send your changes to your remote server?

# git push origin master
 # git push

So how do you get changes others have uploaded to your server?

# git pull origin master
# git pull

Note that origin is the name of your remote and master is your branch.

If you started your git repo from scratch (git init), then you don’t have a remote setup. To add your origin remote

# git remote add origin

Git Branches and Tags
Please read ProGit. A summary won’t do it justice especially cos u’re already have an idea about branches and tags.

Git Submodule
At a point, you may want to have a repo in a repo. Thats where Git Submodule comes in. For example, you what to add debug kit to your cakephp project.

Lots of people hate submodule cos u of some extra work it adds if you update your plugins regularly. Note that it is absolutely essential you understand the pitfalls of submodule before using it otherwise you’ll … urhhh … end up in a pit.

Ignoring Files
There are two main scenarios where you’ll like to ignore files. First scenarios is when you have files that are inevitably in the project directory but are not part of the project. e.g Temporary files, cache, session files, IDE config files etc. These are files that you don’t want to add to the project at all. To achieve this you can use a file which should be in the root of your project .gitignore. It should contain a list of files and directories that you what ignored.

NOTE that this does not affect versioned files. If you what to ignore versioned files, you’ll have to remove the file from the project first before git will ignore it.

# git rm <file>

The second case is a file does belong to the project but you don’t want git to notice changes to the file at all. For example, in CakePHP, app/config/core.php and app/config/database.php are two very essential files but if you commit your local copy of these files to your main repository/production server you’ll most likely get angry calls real soon from your team-mates or clients. The solution is simple

# git --update-index assume-unchanged <filename>

This totally ignores changes to these files. So if you all commit and push all changed files, the files you’ve applied this to will be ignored. 😀


Quick Start to Git Submodule

The Problem

As a developer, having loads of reusable code makes work much easier and enjoyable. I’ve got into the habit of breaking the applications I develop in CakePHP into plugins so I can reuse the plugins in other projects. It wasn’t long before I hit some issues. For example, I used plugin X in project A. Then copied plugin X to project B and added new functionality. Not so long after that I extended plugin X in project A. So now I have two “branches” of plugin X and merging them is another task altogether. That project A and project B are git repos doesn’t help either since I don’t want to merge project A and project B.

Continue reading