To commit, Perforce, to Git

"ZOMG! Not another git for noobs!" you say.

Well, yes. But mine is special.

I think most people get to git through svn, whereas I have been using Perforce for yonks. While I fell for git pretty quick, there were somethings that took me a silly amount of time to adjust to. So here is a flying introduction to git, through the lens of Perforce.

The largest difference are the easiest to take in stride. Perforce is a central server - Git is distributed. The implications and repercussions are obvious. Perforce tags local files by changing their write permissions. All change history is stored on the server. The link between the depot version of the files and the local version is maintained more or less by collusion.

For Git all depots are local. The change history is maintained in a  parallel directory structure. The link between files and history is maintained with CRCs. This leads to my favorite feature of Git: make your changes and then worry about source control. A fairly common Perforce problem is to edit a file without checking it out. Yes, I know, terrible practice. However if you are in the middle of being productive, it can wreck your flow to have to worry about CM.

For perforce you would be doing:

p4 edit file

In git you do:

git add filepattern

In practice I nearly always am doing:

git add .

which just says "everything that I have changed from this location down, add to my changelist".

Alright, I latched onto that quite quickly. Yay, I don't need to open for edit beforehand! Except there is a step that you ought to do first with Git, just to make your life easier.

git checkout -b ThingThatIAmWorkingOn

What that does is create a new branch and move you on to it. Why? This isolates your changes. I know a lot of guys who have tones of simultaneous changelists in Perforce. In Git it is easier to have tones of branches. So as a rule of thumb, before you start work create a new branch to isolate your changes.

Here is one of the issues that hung me up for a while.  You make a change in Perforce, you don't like it, you revert it.

p4 revert [-c changelist#] file

The parallel command in Git isn't obvious, until you know it. In Git, by "add"ing a file you are "staging" it - preparing to commit it. Unstaging a file is accomplished by:

git reset HEAD file 

On of the things that git actually makes conceptually easier is moving and removing files. If you have every done file maintenance from a command line this should look very familiar. To remove a file or group of files you do:

git rm filepattern

Moving or rename files is about the same:

git mv filepattern-src dest

At this point we want to submit our changes. In perforce that would be:

p4 submit changelist

Git handles this through:

git commit

This is going to commit all of the staged files that we previously added. Personally, I am addicted to

git commit -m "this is a commit message"

which commits and specifies the message at the same time.

Most of the time, you are going to be creating a repository based on some other, probably remote, repository.

git clone

After cloning you can pull down changes and push up changes, the analogs of sync and submit.

git pull 

git push  

So really, in order to get you changes to a central repository there are two steps, the local commit and then the push to the remote repository.

I'll finish up with a summary workflow:

git clone git://myproject.org/repo/repo.git

git pull origin master

git checkout -b newtask

edit my stuff

git add .

git commit -m "all the lovely changes I have made" 

git checkout master

git merge newtask

git mergetool

git commit

git push origin master