↓ Archives ↓

Posts Tagged → git

September 5th, 2011

Make gitk look better by updating tk

I thought I’ve already done this to all of my machines but it seems that I haven’t done it on this laptop I’m using right now.

Anyway, I use gitk for my graphical git browsing because I’m too lazy to download other graphical packages. Unfortunately, gitk looks like this:

pre-tk8.5
(click pic for larger version)

The solution to this is to install tk8.5 and tell gitk to use it instead of 8.4. From SU:

To fix this the Debian (Ubuntu) way:

$ sudo apt-get install tk8.5
$ sudo update-alternatives --config wish

And then pick the wish8.5 alternative.

Here’s the result:

post-tk8.5

This post by Bryan Bibat is from existence, refactored.

By Bryan Bibat • Posted in Uncategorized • No Comment
September 2nd, 2010

How to avoid breaking builds

git The guy I’m mentoring right now in one of my freelancing gigs is fairly new to software development so I decided to give him a couple of guidelines (conveniently posted on the project’s wiki) on how to properly use git. Hopefully this should spare me the horrible flashbacks to the days when everyone I was working with was consistently breaking builds everyday.

Best Practices

  • Commit often. The more you commit, the easier it is to do stuff like rolling back changes or pinpointing where a change was committed.
  • Put a meaningful comment every commit. You’ll be thankful you did that 3-6 months down the line when you’re trying to verify if a certain piece of code is a bug or a feature.
  • Push with care. Follow the procedure below to avoid breaking the build i.e. pushing a version of the code which doesn’t work.

Proper Version Control Procedure

Before you push your code to the repository, please follow the following procedure:
  • If you still haven’t done it yet, commit your changes to your local repository (git add and/or git commit -a -m).
  1. Pull the changes from the remote repository (git pull).
  2. In case of conflict, manually edit the conflicting files.
    • You may have to collaborate with the other dev for this.
    • After fixing the conflict, commit the merged changes and go back to step 1 (git pull).
  3. Run the DB migrations.
  4. Run the RSpec tests.
    • If the specs fail, either fix the code or fix the specs.
    • After fixing the failing specs, commit the fixes and go back to step 1.
  5. Run the Cucumber tests.
    • If the specs fail, either fix the code or fix the features.
    • After fixing the failing features, commit the fixes and go back to step 1.
  6. Do a simple developer test. Open the server, log in, and open a couple of pages.
    • If the system doesn’t work, find the problem and fix it.
    • After making the system run smoothly again, commit the fixes and go back to step 1.
  7. You can now push your changes to the remote repository using git push.
You might notice that we’re using RSpec and Cucumber in our project. I’ll talk more about them in a later post.

This post by Bryan Bibat is from existence, refactored.

By Bryan Bibat • Posted in ruby • No Comment
May 7th, 2010

Command aliases for Subversion, Git and Rails

I got a Peepcode unlimited last year which came with a nice video about the command line. Check it out.

Not too many people will find this interesting. For me, it's something I just want to do for myself (and for those I'd work for if I'm still employed).

Aliases matter

I haven't organized my aliases into a separate file as shown in the video but I am using some useful aliases right now.

These are some of the aliases I have:

alias start_mysql="/Library/StartupItems/MySQLCOM/MySQLCOM start"
alias stop_mysql="/Library/StartupItems/MySQLCOM/MySQLCOM stop"
#adds all new and modified files for a git repository
alias ga="git add ."
#adds all new files for subversion 
alias sa="svn status | grep "^\?" | sed -e 's/? *//' | sed -e 's/ /\\ /g' | xargs svn add"

I find Rails 3 commands much more confusing than the old ones although they seem to be nearly the same. Plus it gets a little complex considering I'm using different versions. For those following through my posts regarding Rails on OS X/ Linux, you'd probably find this useful.

#The new command to install a plugin in Rails 3 (subject to change - probably) 
ruby script/rails plugin install plugin_repository

A little long right? This is what I need for sanity:

alias plugin_install="ruby script/rails plugin install"
#use Rails3 for Ruby 1.8.7 
alias r3="rvm 1.8.7%rails3"
#use Rails3 version and starts the rails app
alias rs="rvm 1.8.7%rails3 && rails server"

Sweet. Now I can sleep. Zzzz...

This post by Katz Pe is from BridgeUtopia.

By Katz Pe • Posted in rails • No Comment