I ett tidigare inlägg om Distribuerad versionshantering med Git nämnde Robert hur man kan lägga in lite smarta saker i ~/.bashrc om man använder bash-shell. Då kan man på ett tydligt sätt se vilken branch man använder och om det finns filer som inte är add:ade till git-repositoriet.

~/.bashrc

function parse_git_dirty {
  [[ $(git status 2> /dev/null | tail -n1) != "nothing to commit (working directory clean)" ]] && echo "*"
}
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/[\1$(parse_git_dirty)]/"
}
export PS1='${debian_chroot:+($debian_chroot)}\[33[01;32m\]\u@\h\[33[00m\]:\[33[01;34m\]\w\[33[00m\]$(parse_git_branch)\$ '

Då ser prompten ut nåt sånt här:
johnny@puma-ubuntu:~/dev/projects/cygni/demo-stuff[master*]$

Som ni ser så syns det tydligt att master-branchen används och * indikerar att det finns filer som inte är inlagda i Git-repot.

Git-konfiguration

Utöver detta kan man skapa filen ~/.gitconfig för att underlätta det vardagliga arbetet med Git. Dels kan man skapa olika alias – exemplet nedan visar hur git st kan användas istället för git status. Du kan även ange namn/e-post som gör att dina pushar/commits ser lite snyggare ut. Color-sektionen underlättar oerhört mycket om du använder ett shell och Git tillsammans. Då får du helt enkelt color-coding i prompten vilket gör att Git-outputen blir enklare att läsa!

~/.gitconfig

[user]
  email = johnny.puma@acme.se
  name = Johnny Puma

[alias]
  st = status
  ci = commit
  br = branch
  co = checkout
  df = diff
  lg = log -p

[color]
  ui = auto

Om man vill använda JConsole eller VisualVM för att övervaka en JVM som ligger på en dator som man inte har tillgång till från sin egna dator utan endast via en annan dator som man i sin tur har ssh access till, så kan man sätta upp en lokal SOCKS tunnel som man kör genom mot den remota ssh servern. (Läs mer…)

Det finns nu en open-source variant av IntelliJ. Det finns en del begränsningar i den, och när man läser listan förstår man att Jetbrains fortfarande hoppas få in licenspengar från stora kunder: Perforce-stödet (typiskt storprojekts/storföretags-SCM) är ett exempel. Men ändå!

Vi på Cygni som gillar IntelliJ måste förstås kontra när vi ser sådana här bra Eclipse-tips på bloggen.

Jag kom därvidlag att tänka på s.k. Live Templates i IntelliJ. De är en slags kortkommandon som är kopplade till parametriserade kodsnuttar.

Om man trycker Ctrl+J när man är i en Java-fil, så får man se något i den här stilen:

Listan över Templates

Listan över Templates

Man kan begränsa listan genom att skriva en del av ett kortkommando (t.ex. ”it”) innan man trycker Ctrl+J. Efter ett tag lär man sig förstås kortkommandona utantill – då är det bara att skriva ”itar” eller vad det nu är och sedan trycka Ctrl+J så får man sin kodsnutt.

Detta vore inte så märkvärdigt om det inte vore för det faktum att man kan skapa sina egna Live Templates.

(Läs mer…)

Vi har tidigare diskuterat lite sköna snabbkommandon för Eclipse i inlägget Eclipse Tips och Tricks. Då nämndes bland annat Ctrl-Shift+F för att formatera koden och Ctrl+Shift+O för att organisera importer.

I Eclipse finns något som kallas för Save Actions under Window -> Preferences och sedan Java -> Editor -> Save Actions. Där kan man ställa in en hel del saker som automatiskt ska ske när du sparar en fil exempelvis:

  • Formatera koden enligt dina inställningar
  • Organisera importer / ta bort onödiga importer
  • Sortera medlemmar (metoder och attribut)
  • Ta bort ”trailing whitespace”
  • Fyll ut med måsvingar och parenteser där det saknas
  • Ta bort onödiga castningar
  • etc

Om du gillar att ha ordning och reda i dina källkodsfiler kan jag rekommendera detta. Det är dock viktigt att man bestämmer vilka formateringsregler som ska gälla i det aktuella projektekt och att alla använder dessa regler. Annars kan filerna förändras för mycket mellan varje incheckning. Om någon exempelvis använder tabbar och någon annan använder mellanslag så kommer filerna att diffa stort fast man kanske bara har gjort en mindre förändring.

Självklart kan detta arbetssätt vara problematiskt ifall du sitter i en existerande kodbas som inte är bra formaterad – varje ”Save” kan leda till att den aktuella filen förändras kraftigt på grund av formateringen och det kan det bli svårt att se vad som egentligen förändrats i filen mellan två versioner. Detta är ju dock ett problem som försvinner över tiden eftersom alla filer så småningom är formaterade.

« Föregående sidaNästa sida »