Git merging

Usually one wants to merge a branch back into the master (or "trunk" equivalent branch).
To do so simply used:

git checkout master (for instance)

followed by

git merge BRANCH_NAME

Bare in mind this means you explicitly are not attempting to hide the fact you have branched and that the branch will be committed to the remote repository if you git svn dcommit.

You can then remove the merged branch using

git -d BRANCH_NAME

This gives a tree structure similar to this:

   /----------------\ <- BRANCH_NAME
------------------------------------- <- *master

where / represents the branch out and the \ represents the merge back into the master branch.

This is not very elegant unless you want to share remote branches, if you are just working with your branch locally (as you would be if you are using git over SVN), then rebase is probably the nicer option (see coming post). Thoughts?

Git branches

This is most certainly one of the most powerful features in git compared to tradition CVS/SVN systems.

1. you can branch locally, without affecting the remote directory - that's very cool
2. as we will see in later posts you can either merge or rebase your branch to the trunk (this defines the way your branch will get committed remotely: if you merge, you see the branch as a separate "path" in your remote repository, if you rebase, you can make sure your commit ends up looking like part of the trunk "path") - again very cool

So, here are the basics, use:

git branch

to view all current branches, the star indicates which branch you are currently working in

git branch BRANCH_NAME

to create a new branch

git checkout BRANCH_NAME

to start working in that branch

git checkout master

to revert to the master (main) branch

git merge BRANCH_NAME

to merge BRANCH_NAME into another branch (for instance master)

git rebase BRANCH_NAME

to rebase BRANCH_NAME into another branch (for instance master)

git branch -d BRANCH_NAME

to delete a given branch

git branch -D BRANCH_NAME

to force delete a branch

git checkout BRANCH_NAME

to checkout a branch and start (or continue) working on it
More information about the difference between merge and commit coming soon.
Thoughts?

Git hashes

Git identifies all its objects with a SHA-1 (40 byte) hash identifier.
This way git uniquely identifies :
- blobs (files)
- trees (groups of files and/or other trees)
- commits (a single tree)
among others.

If you type:

gitk

you will be able to see every single commit, their hashes, as well as all the files of each commit and their hashes
You can use commands such as:

git log 540991f 

to view blob content,

git ls-tree

to view tree information,

git show

for information about commits,

And so on and so forth.

Note the git is constructed around the concept that most hashes are very different and that the beginning of the hash is sufficient to identify the complete hash. That's what I did above in the git log command: used the shortened hash, which actually identifies a single blob in my system.

Use git help for more information on command options.


Thoughts?

Working locally with git

Now we have worked out how to interact with an SVN repository, let's see how we can work with git locally.

Git has three "areas" you can work in:
- the working area - this is where you program
- the staging area - this is where you store the files that have changed and you would like to include in an upcoming commit
- the repository - this is where everything that has been committed is stored (and when I say everything I mean everything - every single snapshot you have committed is stored here)

The trick with git is to get files from one place to another satisfactorily.

Here are the basic commands to do that:

git status

set a list of changed files, files prepared for commit, and unfollowed files (you can make git ignore changes to certain files like target build files, and so on and so forth).

Once you have the status, you can check differences for any of the files listed in the staging are using:

git diff FILE_PATH

You can also add unstaged files to the staging area:

git add FILE_PATH

And vice versa

git checkout -- FILE_PATH

Once you have added all the files you want to the staging area, you can commit your changes:

git commit -m "my commit message"

You have just created a local commit.

We will see in some of the next posts how the data is stored and the powerful things we can do with local commits before sending them through to the central repository.

Thoughts?

Basic git commands

We'll be using a classic configuration of Git over SVN. In other words, we will be running and "old" SVN repository with Git clients so that we get all the flexibility of Git without having to change the server configuration and migrating all of the source code to Git.

The first obvious thing one wants to do in such a situation is to get hold of some project in the repository. There are several ways of doing this. One simple way is to get oneself into a cosy directory where we want a project to land and initialize the git repository like so:

git svn init -s PROJECT_URL LOCAL_DIR_NAME

and then go fetch it:

git svn fetch

If you want to make sure you are up to date simply type:

git svn rebase

and if you want to commit changes centrally use:

git svn dcommit

Thoughts?

Git overview

We've all heard of CVS, SVN... and now more flexible systems such as Git.

This a quick overview of the power of Git over SVN for instance.

There are several differences between our habitual CVS/SVN versioning systems and Git:
- SVN stores deltas between files that have changed in every commit; Git stores compressed "snapshots" of every commit
- SVN stores its data centrally; Git stores its data both centrally and locally.

These two main differences result in several advantages of Git:
- because everything is stored locally, you can work offline if the network is down
- because everything is stored locally and remotely, you can lose your central server and not lose anything
- because all snapshots are store locally, diffs are really quick, no need to have a working central server, nor to get the files across the network
Thoughts?