środa, 24 września 2014

Simple Git Cheat Sheat

Dzisiaj w ramach utrwalenia pracy z gitem, postanowiłem spisać krótką ściągawkę, komend których używam najczęściej.

Ustawienia globalne:

git config --global user.name "Łukasz Szewczak"
git config --global user.email "lukaszewczak@gmail.com"

Tworzenie klucza ssh:

ssh-keygen -t rsa -C "lukaszewczak@gmail.com"
Następnie kopiujemy klucz publiczny z folderu ~/.ssh/id_rsa.pub do kluczy SSH na swoim profilu na serwerze GitLab lub GitHub

Tworzenie repozytorium

mkdir angularjs-styleguide
cd angularjs-styleguide
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@192.168.1.100:nazwa-projektu.git
git push -u origin master

Dodanie zdalnego repozytorium do istniejącego lokalnego repozytorium

cd existing_git_repo
git remote add origin git@192.168.1.100:nazwa-projektu.git
git push -u origin master

Klonowanie repozytorium



git clone git@191.168.1.179:nazwa-projektu.git
Powyższa komenda pobierze kod ze zdalnego repozytorium i utworzy lokalne repozytorium w folderze nazwa-projektu
cd nazwa-projektu

Sprawdzenie statusu repozytorium


git status

Dodanie pliku/plików do cmmita


git add . - Dodaje wszystkie pliku
git add nazwa-pliku - Dodaje konkretny plik

Usunięcie pliku/plików z commita


git checkout . - Usuwa wszystkie pliki
git checkout nazwa-pliku - Usuwa konkretny plik

Commit zmian


git commit -m "komentarz opisujący wprowadzane zmiany"

Praca ze zdalnym repozytorium

git remote -v - Wyświetlanie zdalnych repozytoriów
git push - Wypychamy zmiany do zdalnego repozytorium

Pobranie info ze zdalnego repo

git pull - pobiera automatycznie dane ze zdalnego repo (fetch) dla bieżącej gałęzi i scala je (merge) z lokalnymi plikami
git fetch - Polecenie to sięga do zdalnego projektu i pobiera z niego wszystkie dane, których jeszcze nie masz. Po tej operacji, powinieneś mieć już odnośniki do wszystkich zdalnych gałęzi, które możesz teraz scalić z własnymi plikami lub sprawdzić ich zwartość. Fetch nie robi merga.

Sprawdzenie ostatnich zmian


git show

Prace z branchem


Tworzenie brancha



git checkout -b test - Tworzy nowego brancha o nazwie test i przełącza się na tego brancha

Przełączenie się na brancha


git checkout branch-name
Jeżeli chcesz mieć dostęp do brancha stworzonego przez kogoś z zespołu należy wykonać poniższe kroki

git fetch origin
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From git@github.com:schacon/simplegit
 * [new branch]      serverfix    -> origin/serverfix

Podczas pobierania ściągasz nową, zdalną gałąź, nie uzyskujesz automatycznie lokalnej, edytowalnej jej wersji. Inaczej mówiąc, w tym przypadku, nie masz nowej gałęzi serverfix na której możesz do razu pracować - masz jedynie wskaźnik origin/serverfix którego nie można modyfikować.
Aby scalić pobraną pracę z bieżącą gałęzią roboczą uruchom polecenie git merge origin/serverfix.

Jeśli potrzebujesz własnej gałęzi serverfix na której będziesz mógł pracować dalej, możesz ją stworzyć bazując na zdalnej gałęzi w następujący sposób:
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch "serverfix"

Otrzymasz lokalną gałąź, w której będziesz mógł rozpocząć pracę od momentu, w którym znajduje się ona w zdalnej gałązi origin/serverfix.

Wylistowanie zdalnych gałęzi


git branch - Pokazuje tylko lokalne gałęzie
git branch -a - Pokazuje lokalne i zdalne gałęzie
git branch -r - Pokazuje tylko zdalne gałęzie
$ git branch
* master

$ git branch -a
* master
  origin/1-2-stable
  origin/2-0-stable
  origin/master

$ git branch -r
  origin/1-2-stable
  origin/2-0-stable
  origin/HEAD
  origin/master


Odtwarzanie repozytorium



Git jest fajny :-) naprawdę :-), ale jeżeli ulegnie uszkodzeniu Twoje lokalne repozytorium to szanse na jego pełne przywrócenie są marne, w takiej sytuacji trzeba się liczyć ze stratami i utratą ostatnich lokalnych commitów, dlatego warto często wysyłać zmiany na serwer. Poniżej opisana jest procedurą która pomaga odzyskać działające repozytorium (przynajmniej mi kilka razy pomogła :-) ):
Poniższa procedura zakłada, że folder zawierający popsute repozytorium nazywa się foo oraz że poniższe komendy wywołujemy z katalogu zawierającego folder foo, a zatem do dzieła:
1. Tworzymy backup uszkodzonego repozytorium: cp -R foo foo-backup
2. Klonujemy zdalne repozytorium do nowego katalogu git clone@riscoserver05:foo foo-newclone
3. Usunąć uszkodzony podfolder .git: rm -rf foo/.git
4. Przenieść nowy sklonowany folder .git do fodleru foo: mv foo-newclone/.git foo
5. Usunąć folder zawierający sklonowany projekt: rm -rf foo-newclone
Po powyższych operacjach w folderze foo mamy z powrotem działające repozytorium oraz wszystkie lokalne zmiany które teraz można będzie zakomitować i wysłać na serwer. Powodzenia !! :-)

piątek, 19 września 2014

Remote debugging web pages with weinre

Ostatnio pisałem aplikację mobilną używając frameworka Sencha Touch. Aplikacja miała ładne niebieskie tło dzięki użytemu zdjęciu :-). Testowałem aplikacje lokalnie na laptopie używając przeglądarki chrome oraz emulatora Ripple i wszystko wyglądało super. Zainstalowałem aplikację na tablecie z androidem i po uruchomieniu aplikacji ku mojemu zdziwieniu, aplikacja miała białe tło i ani śladu po moim ładnym niebieskim obrazku w tle :-(.... I co teraz?? Jak sprawdzić w czym leży problem. Na laptopie w przeglądarce włączę sobie narzędzie do debugowania np.: firebuga na friefoxie lub developer tools na chromie, ale na tablecie nie ma takiej możliwości..... Na szczęście nie wszystko stracone i nie trzeba kombinować metodą prób i błędów a wszystko dzięki narzędziu weinre przeznaczonemu do zdalnego debugowania aplikacji webowych czyli pracując na laptopie możesz debugować aplikację webową odpaloną na twoim tablecie lub telefonie.

Weinre jest aplikacją napisaną w node.js, dlatego do jej instalacji potrzebujemy zainstalowanego środowiska node. Samą aplikację weinre instaluje sie używając poniższej komendy


Sprawdźmy czy aplikacja zainstalowała się poprawnie wpisując komendę weinre ?

Wszystko wygląda dobrze. Podczas użytkowania aplikacji weinre w interakcje wchodzą trzy programy:

  • debug server - serwer http odpalany przez komendę weinre 
  • debug client - interfejs www do debugowania zdalnej aplikacji 
  • debug target - jest to aplikacja webowa którą chcesz debugować, przeważnie będzie to aplikacja uruchomiona na urządzeniu mobilnym.  

Zatem odpalmy nasz debug serwer po przez poniższą komendę.

Aplikację uruchomiłem z dwiema opcjami
  • pierwsza opcja --httpPort ustawia port na którym będzie działać debug serwer
  • kolejna opcja to --boundHost którą należy ustawić na wartość -all-, aby weinre nasłuchiwał na wszystkich adresach sieciowych. Dzięki temu nasza aplikacja uruchomiona na urządzeniu mobilnym będzie się mogła połączyć z naszym desktopem/laptopem.
Po wykonaniu powyższej komendy otwieramy przeglądarkę i wpisujemy adres http://localhost:8081 i jeżeli nie było żadnych problemów powinniśmy zobaczyć zgłoszenie się serwera weinre




  • W sekcji Access Points widać adres url do aplikacji webowej służącej do debugowania naszej aplikacji
  • Natomiast w sekcji Target Script znajduje się skrypt który należy osadzić na stronie którą chce się debugować. Oczywiście należy zamienić nazwę localhost na adres ip maszyny na której uruchomiliśmy serwer do debugowania.
Po wejściu na adres http://localhost:8081/client/#anonymous dostajemy interfejs zbliżony do narzędzi debugowania znanych z chroma lub z safarii.

Ponieważ na tą chwilę nie uruchomiłem żadnej aplikacji do debugowania sekcja Targets jest pusta.

Natomiast po odpaleniu aplikacji na tablecie, na laptopie widzę informację o podłączanym urządzeniu.



W tym momencie możemy przystąpić do debugowania aplikacji, możemy wejść w zakładkę Elements, aby podejrzeć strukturę strony oraz użyte style. Możemy wyświetlić konsolę, aby zobaczyć jakieś zgłoszenia z naszej aplikacji lub wykonać jakiś prosty kod js.


Narzędzie weinre nie rozwiąże wszystkich naszych bolączek ale jest zdecydowania narzędziem bardzo pomocnym zwłaszcza jeżeli piszemy mobilne aplikacje webowe. Po więcej szczegółów odnośnie samego weinre odsyłam do strony projektu http://people.apache.org/~pmuellr/weinre-docs/latest/Home.html