I’ve started using Git distributed source code control recently and I have to say I love you, Git. I used to complain and be blocked when I was working with Team Foundation Server and that for some reason, the TFS server was down. Now, I just don’t worry about that because Git allows me to have my own local repository which is then merged to the server one.
The transition from TFS or SVN to Git may be a bit tedious but it’s worth the try.
I will use the tool I need depending on the project I will work on, but for now, I’m fully enjoying the ride with Git. Find it here.
GitHub
Git is a very cool to use, even if at first you will be typing a lot into a command shell. If you love learning, you can read the ProGit free online book here.
I use GitBash for that.
GitBash with Console2
I find myself a lot of time using the following commands:
Git status: checks current status of environment.
Git add *: Will add untracked files to my local repository.
Git pull –rebase: Get latest from server and apply my changes on top.
Git commit -am: Commit my changes to my local environment.
Git push origin [branchname]: Push my committed changes from my local environment to the server.
Git checkout: Checkout a branch or paths to the working tree. Allows me to switch branches.
I also use:
Gitk: Open the Git repository browser.
Gitk – Git repository browser
Check here for some doc on Git commands.
If you want to get started with Git, you can always check the reference site built by GitHub.
It will give you info about the useful Git commands.
The following note comes from the reference site.
Git doesn’t have a central server like Subversion. All of the commands so far have been done locally, just updating a local database. To collaborate with other developers in Git, you have to put all that data on a server that the other developers have access to. The way Git does this is to synchronize your data with another repository. There is no real difference between a server and a client – a Git repository is a Git repository and you can synchronize between any two easily.
Here are examples of how you would use Git.
git add adds file contents to the staging area
In Git, you have to add file contents to your staging area before you can commit them. If the file is new, you can run git add to initially add the file to your staging area, but even if the file is already “tracked” – ie, it was in your last commit – you still need to call git add to add new modifications to your staging area. Let’s see a few examples of this.
Going back to our Hello World example, once we’ve initiated the project, we would now start adding our files to it and we would do that with git add. We can use git status to see what the state of our project is.
$ git status -s ?? README ?? hello.rb
So right now we have two untracked files. We can now add them.
$ git add README hello.rb
Now if we run git status again, we’ll see that they’ve been added.
$ git status -s A README A hello.rb
git commit records a snapshot of the staging area
Now that you have staged the content you want to snapshot with the git add command, you run git commit to actually record the snapshot. Git records your name and email address with every commit you make, so the first step is to tell Git what these are.
$ git config --global user.name 'Your Name' $ git config --global user.email you@somedomain.com
Let’s stage and commit all the changes to our hello.rb file. In this first example, we’ll use the -m option to provide the commit message on the command line.
$ git add hello.rb $ git status -s M hello.rb $ git commit -m 'my hola mundo changes' [master 68aa034] my hola mundo changes 1 files changed, 2 insertions(+), 1 deletions(-)
Now we have recorded the snapshot. If we run git status again, we will see that we have a “clean working directory”, which means that we have not made any changes since our last commit – there is no un-snapshotted work in our checkout.
$ git status # On branch master nothing to commit (working directory clean)
git push push your new branches and data to a remote repository
To share the cool commits you’ve done with others, you need to push your changes to the remote repository. To do this, you run git push [alias] [branch] which will attempt to make your [branch] the new [branch] on the [alias] remote. Let’s try it by initially pushing our ‘master’ branch to the new ‘github’ remote we created earlier.
$ git push github master Counting objects: 25, done. Delta compression using up to 2 threads. Compressing objects: 100% (25/25), done. Writing objects: 100% (25/25), 2.43 KiB, done. Total 25 (delta 4), reused 0 (delta 0) To git@github.com:schacon/hw.git * [new branch] master -> master
Pretty easy. Now if someone clones that repository they will get exactly what we have committed and all of its history.
If you haven’t yet, I suggest you create your GitHub account, start taking a look at Git and even learn easily here if you have 15 minutes to spend.
PATRICK 