Git in easy steps – branch

This is the third part in a series

Then what is a branch in Git, actually? A branch in Git is simply pointer to the hash of a commit (which will be the HEAD commit of that branch), and a name of your branch, of course. That means creating a branch in Git is extremely cheap and is almost instantous.

Now if you look back at the branch tree in Git Extensions, you will see a linear tree. (It’s not something you usually see in your working environment, but we’re new anyway.). You can see that the name of the branches and the commit message are in bold.

For the commit, it means the commit is the HEAD commit of a active branch. A commit will always point to it parent (or its parents, in case of a merge). When you know the HEAD commit, you can know how does your branch look like, down to the initial commit (which has no parent).

Continue reading “Git in easy steps – branch” →

Git in easy steps – amend and stash

This is the second part in a series

Git in easy steps – the basic

Git in easy steps – amend and stash

Git in easy steps – branch

Fixing your commit:

Sometimes, you make a mistake committing something. A file can be missing, or the indentation is not perfect, or you had a typo in your commit message. If you are using some other source control softwares such as Team Foundation Server you’re done with that. The only option you have is to check in another change set to fix your previous one (in case you have a typo in your commit message, be done with that). Git is so much more powerful in terms it allows you to rewrite history.

To fix a commit, make a change, then commit as usual, but this time, Select the “Amend commit” checkbox:

Always think twice before doing this

Continue reading “Git in easy steps – amend and stash” →

Git in easy steps – the basics

This is the first part in a series

Git in easy steps – the basic

Git in easy steps – amend and stash

Git in easy steps – branch

Why Git Extensions.

The war of version control systems was over. Git has won. And that is not an over-statement. CSV, SVN, TFS were the past. Mercurial was close, but GitHub put the end of it. The popular of open source platform makes Git an unambiguous choice for almost every developer in the field . Even BitBucket, the service which once known for Mercurial, supports Git for now. If you start a new project today, Git should be your first and foremost option – well, unless your boss says otherwise.

But the end of a war does not mean everything else is settled. The war of Git clients continues. How many Git clients do we have? I lost count, but at least: Git bash (with comes as the default), TortoiseGit, SourceTree, and of course, Git Extensions. It reminds me a lot of the JavaScript frameworks’ war recently: “There are too many frameworks out there, let’s create a new one to rule them all”. Of course, Git clients’ war is in much smaller scale (You won’t see new Git clients every week), but that does not make it less intense. Git clients are used in a daily basis, and it really affects your productivity, and in some way, your moral as well.

Continue reading “Git in easy steps – the basics” →

Learn Git in … 30 days

Recently I stumbled on a tutorial named Learn git in 30 minutes. While there is nothing wrong with that tutorial, it’s actually pretty accurate, and clear and easy to follow – thumbs up to the author about the writing – I have great concerns about how should we learn Git.

Git is not that easy.

Don’t get me wrong, Git is a great tool, perhaps the greatest developers’ tool since C language. Where I work at, we switched from Team Foundation Server to Git two years and a half ago, and I’ve never looked back – Git does things right where TFS did wrong. It really helped my life, as a developer, easier.

But everything comes at a cost.

As powerful and flexible as it is, Git is also complex and easy to mess up. It can be your best tool, but it can also be your worst nightmare, when something goes wrong.

Continue reading “Learn Git in … 30 days” →