git
Useful git tutorials
Jan 19th
We’ve been using git for as our version control management system since the day we started, and have never looked elsewhere. It’s fast and easy to use and with github, it’s even gone social!
So, for those of you who have heard of git, but don’t really know how it works, and are interested to learn, here are some of the very useful git tutorials that have helped us with our understanding of git and how to work with it.
Of course, the biggest repository for git tutorials is Gitcasts, but our favorite from that lot is Scot Chacon’s git talk at RailsConf 2008
Other good tutorials sites are:
http://net.tutsplus.com/tutorials/other/getting-the-hang-of-github/
http://net.tutsplus.com/videos/screencasts/terminal-git-and-github-for-the-rest-of-us-screencast/
http://www.gitready.com/beginner/2009/03/09/remote-tracking-branches.html
Happy learning! If you’ve got other git resources you liked, put them in our comments and we’ll be happy to update our post with it!
git svn can't locate SVN/Core.pm
Dec 7th
I had a problem when running git svn command on my ubuntu.
Can’t locate SVN/Core.pm in @INC
It turns out all I had to do is install libsvn-perl.
Make your bash aware of git branch on Ubuntu
Jul 3rd
If you’re someone who has multiple git branches on a project and seem to always do git branch to check which branch you’re in. Then here’s how you can make your bash aware of a git branch.
Well, I’m not sure if this works on others, but it sure does works in my Ubuntu Hardy. Just edit your .bashrc at your home folder.
vim .bashrc
Add the following at the very bottom of your .bashrc
[sourcecode language='cpp']
parse_git_branch() {
git branch 2> /dev/null | sed -e ‘/^[^*]/d’ -e ’s/* \(.*\)/(\1)/’
}
PS1=”${debian_chroot:+($debian_chroot)}\u@\h:\w\$(parse_git_branch) $ ”
[/sourcecode]
After that, save it and restart your terminal. You should see something like this at your terminal:
fadhli@atlantis:~/projects/crimson_mdec(master) $
I have a branch named biz_idea, so after a git checkout biz_idea
Switched to branch “biz_idea”
fadhli@atlantis:~/projects/crimson_mdec(biz_idea) $
How the Rails Core team uses git
Jul 2nd
The beauty of git is there is no one true way to do it. Here’s how the Rails Frameworks maintainers uses git.
http://rails.lighthouseapp.com/projects/8994/sending-patches
And here’s a wonderful video from Railscast on how to contribute to Rails.
Git in a team.
Jul 2nd
So , after doing a little bit of homework, this is how I’m gonna do it. I’ll try the forking approach. Assuming that the repo is forked from a repo in github.Taken from Dr Nic’s website http://drnicwilliams.com/2008/02/03/using-git-within-a-team/
Forking is to clone an entire remote repository into another
remote repository. Now you have two repositories based around the
same code base. At that one point in time, they have the same set of
files and the same history of changes.
In our case, you’d fork a git repo. Then, you do a git clone of the repo that you’d just forked.
To you, once you’ve forked a repository, then your repository is
your git “origin” and the original repository you forked just
becomes a fork to pull from when you want to synchronise your
repositories. Make sense? Thought so.
At your local machine terminal,
git clone <your_forked_git_repo>
Now, you have your own local repo.
But what if others makes a change to the code? Well, you need to track their changes. Here is how … base on this website.. (http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch)
Enter the following at your own local repo.
git remote add main_repo <the_git_repo_that_you’d_fork_from>
This will add information in your .git/config of another remote repository that you like to remain updated in your local repo.
Then, the following:
git fetch main_repo
The following output will come out
From <the_git_repo_that_you’d_fork_from>
* [new branch] master -> main_repo/master
Then, do this:
git checkout -b main_repo main_repo/master
The command tells git to create a new branch name main_repo and checkout to that repo.
The following output will come out:
Branch main_repo set up to track remote branch refs/remotes/main_repo/master.
Switched to a new branch “main_repo”
If you do
git branch
You’ll see this:
* main_repo
master
The asterisk shows which branch you’re currently in.
If you do
git branch -r
You’ll see the following
main_repo/master
main_repo/no_signup
origin/HEAD
origin/master
origin/no_signup
The origin is your remote repo, while the main_repo is from the repo that you’ve just forked.
To pull from the main_repo, make sure you’re in the main_repo branch first.
To switch to the main repo branch:
git checkout main_repo
Then pull from the main_repo codes:
git pull main_repo
Then, switch back to your master branch
git checkout master
So to merge the main_repo branch to your master. (Make sure you commit your work first before merging with the main repo.)
git merge main_repo
If there’s conflict, if you’re sure about what’s need to be resolve then code away. Git will tell you which files are in conflict state.
So after you’ve done with your codes. It’s time to push it. Again, make sure you’re in your master branch. Just do:
git push
Then, notify the main_repo maintainer to pull from your repo.
This is one way to work within a team that I know. Maybe in time, I’ll find a better way to work with git much more efficiently.
Git. Make sure branch is updated
Jul 2nd
I had to make sure my git branch is updated with my master.
So at my master branch
git pull master
Next, I switched to my branch named ‘feature_super_tag’.
git checkout feature_super_tag
and then
git rebase master
A good explanation of what a rebase does is from these two blogs:
http://jbowes.dangerouslyinc.com/2007/01/26/git-rebase-keeping-your-branches-current/
http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/
Note: It’s a good policy to never work in your master. Make a branch first for any changes you want to do.
Git. Pushing your local branch to remote branch repo
Jul 1st
Assume you have a git branch named experimental and you would like to push it to your remote repository.
Then just do
git push origin experimental
Now other people can see the remote branch if they do git branch -r.
Perhaps they should do a git pull first before the git branch -r.
This should come out:
origin/experimental
If they would like to work on that branch then simply
git branch <your_branch_name> origin/experimental
Don’t forget to git checkout <your_branch_name> first.
Incompetent git!! Or is it?
May 18th
Git used to be, in my vocabulary, a word I use when I’m angry with someone. Now it’s a new word I use to keep my codes version controlled and backed up. Interesting how language can run circles around you
If you don’t know what git is, here’s a detailed explanation on Wikipedia
Here’s a brief tutorial on how to use git to store your development codes. At the end of this tutorial we provide a link for you to download a script we created to automate push and pull from our git server. Note that we’re running this on an Ubuntu server (gutsy) and using Ubuntu desktop (gutsy/hardy) on our computers. Now, if you’re using Microsoft for doing Ruby on Rails – seriously? (git is possible in Microsoft. You can find git tutorials for Microsoft on the web 
)
1. First, install git in your system/server. Open a terminal in your desktop and type the following:
sudo apt-get install git-core
2. Then, create a folder, lets call it myfirstapp
mkdir myfirstapp
3. Enter the directory that you created
cd myfirstapp
4. Initialize the directory created to be git aware
git init
5. Now you have completed initializing your local directory. Test the setup by doing the following:
Create any file in the folder
touch file1
To display the new file created,use this command
git status
It should display something like this
# On branch master
#
# Initial commit
#
# Untracked files:
# (use “git add
#
# file1
nothing added to commit but untracked files present (use “git add” to track)
which means you have succeeded in creating the repository.
6. Commit the file to your local repository.
git add . (Make sure you add the dot in after add)
git commit -m “put your message here”
7. Now, create your remote repository based on your local repository.
git remote
Nothing should display at this stage
git branch -a
Now, it should display something like this
* master
8. Create a remote connection to your centralized server. We use secured shell (ssh) to create a remote connection to our server.
ssh -l foo foo.bar.org
enter the password for foo
9. Create a folder in your home driectory
foo@foobar:~$mkdir myfirstapp.git
Enter the directory created
cd myfirstapp.git
10. Initialize the directory by typing :
git –bare init
Exit from your remote connection:
Exit
11. In case you are not in the repository folder that you have created earlier,change to that directory in your local machine. Add the origin of the remote by typing
git remote add origin ssh://foo@foo.bar.org/home/foo/myfirstapp.git
12. Verify by viewing the the .git/config file
cat .git/config
You should see something like this
[remote "origin"]
url = ssh://foo@foo.bar.org/home/foo/myfirstapp.git
13. Push the changes to the server
git push origin master
14. Edit your .git/config using your favourite editor (our ‘engineers’ use vi. You can always choose to use nano or gedit )
vi .git/config
Now, add the following line
[branch "master"]
remote = origin
merge = refs/heads/master
15. Quit and Save.
You have now created a repository for your codes in your remote server. Now you need to set up your local directory to automatically link to the remote repository to pull codes. Your team mates will need to do the following too to get a copy of the codes (and git setup!). To get the source from the repository, the first step is to clone the source code. In your projects folder, (parent to myfirstapp, for example), type in the following:
git clone ssh://foo@foo.bar.org/home/foo/myfirstapp.git
This will clone your codes from your remote server to your local machine
The next step would be to set the .gitignore files. This file specifies what files to ignore when pushing to the remote server. You would not want to push your log file and other insignificant files to your remote server, won’t you? Use your favourite editor to edit .gitignore. Again, by using vi,
vi .gitignore
Copy and paste the following lines
log/*.log
tmp/**/*
.DS_Store
doc/api
doc/app
These are the file types that you may not want to push to the remote repository. Your requirements may vary, so make sure!. Once you’ve specified the file types to ignore, save and quit the text editor.
You are now all set to pull and push from your server. The following steps detail how you should ALWAYS pull and push to your server
1. First,use the following commands to add your files to your local repository.
git add . (Again, make sure the dot after “add”)
git commit -m “your message here”
2. Next, pull the codes from repository from the remote server in order to avoid any conflicts with existing codes in the remote server (your team mates might have upload codes before you, so they might be in conflict with changes you made to the codes)
git pull
If something is wrong – a conflict, for example, you and your team mate both modified the same lines of code – fix it first.
3. If there are no problems, then you may proceed with pushing your codes to the remote server
git push
Now, the server is updated with your new codes, and others may pull your codes from the repository.
Now as programmers we know very well that it’s easy to overlook one or two of the procedures mentioned above – especially if you’re pushing code at around 2-4 am – so we created a script for us to push our codes without having to bother doing all the above. Oh, did I forget to mention that we’re also lazy?
If you want to you can download the script from here. Remember to remove the .txt extension before using (Scribd quirk, can’t upload if they don’t know your file format) Note that we won’t be held responsible if anything happens to your data or system (In other words, make sure you know the ins and outs of your system and the script before you use it!)
Here are the steps for you to run our script
1. Save the script to the local repository folder in your machine. In this case it would be the myfirstapp folder.
2. Change the file access to executable file
chmod +x pullpush
3. Run the script from the local repository folder
./pullpush
Follow the instructions provided as the script runs (enter passwords etc). You may terminate the script by using ctrl+c (Hey, it ain’t perfect, but it works)
That’s it for our brief git tutorial! Learn to do it, and you can avoid becoming an actual git yourself!
