Userful applications

Scoop

What does Scoop do?

Scoop installs programs from the command line with a minimal amount of friction. It tries to eliminate things like:

  • Permission popup windows
  • GUI wizard-style installers
  • Path pollution from installing lots of programs
  • Unexpected side-effects from installing and uninstalling programs
  • The need to find and install dependencies
  • The need to perform extra setup steps to get a working program

Scoop is very scriptable, so you can run repeatable setups to get your environment just the way you like, e.g.:

scoop install sudo
sudo scoop install 7zip git openssh --global
scoop install aria2 curl grep sed less touch
scoop install python ruby go perl

If you’ve built software that you’d like others to use, Scoop is an alternative to building an installer (e.g. MSI or InnoSetup)—you just need to zip your program and provide a JSON manifest that describes how to install it.

Install Scoop

Run this command from your PowerShell to install scoop to its default location (C:Users<user>scoop):

iex (new-object net.webclient).downloadstring('https://get.scoop.sh')


Afterwards you can install most of the tools directly. For example, to install 7zip:

D:>scoop install 7zip

And you’re done.

Install Scoop to a Custom Directory 

If you wanna have Scoop and the installed aplication in a specific directory, power up your PowerShell and type:

[environment]::setEnvironmentVariable('SCOOP','D:ApplicationsScoop','User')
$env:SCOOP='D:ApplicationsScoop'
iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

Related sites of use:

https://scoop.sh/ 
https://github.com/lukesampson/scoop

AutoHotKey 

https://www.autohotkey.com/
The ultimate automation scripting language for Windows.”

Rapid Environment Editor

https://www.rapidee.com/en/about
Windows environment variables management

Environment variables for Android development

ANDROID_HOME
Deprecated (in Android Studio), use ANDROID_SDK_ROOT instead.

ANDROID_SDK_ROOT

Installation directory of Android SDK package.
Example: C:AndroidSDK or ~/android-sdk/

ANDROID_NDK_ROOT

Installation directory of Android NDK package. (WITHOUT ANY SPACE)
Example: C:AndroidNDK or ~/android-ndk/

ANDROID_SDK_HOME

Location of SDK related data/user files.
Example: C:Users<USERNAME>.android or ~/.android/

ANDROID_EMULATOR_HOME

Location of emulator-specific data files.
Example: C:Users<USERNAME>.android or ~/.android/

ANDROID_AVD_HOME

Location of AVD-specific data files.
Example: C:Users<USERNAME>.androidavd or ~/.android/avd/

JDK_HOME and JAVA_HOME

Installation directory of JDK (aka Java SDK) package.
Note: This is used to run Android Studio(and other Java-based applications). Actually when you run Android Studio, it checks for JDK_HOME then JAVA_HOME environment variables to use.

Log.v(), Log.d(), Log.i(), Log.w() and Log.e() – When to use each one?

I found a wonderful explanation of these on Stackoverflow and I stole them from Kurtis Nusbaum so you won’t have to.

You’re welcome!

So… you come to me and ask:

When and which one to use?

Let me (that is… him) tell you what I stole:

  • Log.e: This is for when bad stuff happens. Use this tag in places like inside a catch statment. You know that an error has occurred and therefore you’re logging an error.
  • Log.w: Use this when you suspect something shady is going on. You may not be completely in full on error mode, but maybe you recovered from some unexpected behavior. Basically, use this to log stuff you didn’t expect to happen but isn’t necessarily an error. Kind of like a “hey, this happened, and it’s weird, we should look into it.”
  • Log.i: Use this to post useful information to the log. For example: that you have successfully connected to a server. Basically use it to report successes.
  • Log.d: Use this for debugging purposes. If you want to print out a bunch of messages so you can log the exact flow of your program, use this. If you want to keep a log of variable values, use this.
  • Log.v: Use this when you want to go absolutely nuts with your logging. If for some reason you’ve decided to log every little thing in a particular part of your app, use the Log.v tag. 

And as a bonus…
Log.wtf: Use this when stuff goes absolutely, horribly, holy-crap wrong. You know those catch blocks where you’re catching errors that you never should get…yea, if you wanna log them use Log.wtf

Git vejenje za budale (Git branching for schmucks)

<Slovenian language>

Ker je za delo (tudi samostojno delo!) branching tako zelo uporabna metoda sem se odločil , da spišem tale kratek potek dela.

Teorija gre nekako tako:

Programer se loti nekega spreminjanja kode za katerega pa ne ve, če bo sploh uporaben. Recimo, da hočete v vaš program dodati možnost izvoza podatkov v Libre Office.
Zato namesto da pišete v MASTER repo raje naredi novo vejo (branch), ki jo poimenuje po spremembi, ki jo želiote izvesti. Torej nekako tako:

Git checkout -b libreOffice

-b je za branch

V ukazni lupini boste zaznali spremembo:
namesto npr:


Hoornet@prostitute /c/Delo/MyWorkDir (master)

Bo sedaj


Hoornet@prostitute /c/Delo/MyWorkDir (libreOffice)

Git vam tako sporoča na kateri veji se trenutno nahajate. Preskok je u šubu. Pri kreaciji nove veje to pomeni, da imate še vedno na voljo vso kodo od prej a lahko sedaj bolj ziheraško spreminjate kodo, saj manipulerate drugo vejo. V kateremkoli trenutku se lahko vrnete na prejšnje satanje.
Ko ste končali s ‘pod-projektom’ se odločite ali boste prelili spremembe v master ali ne. V primeru da je šlo vse ok delujte tako:

Najprej skočite nazaj na master z


Git checkout  master

V trenutku boste nazaj v stanju pred vsemi spremmbami (t.j. v zadnjem stanju pred skokom v novo vejo). Sedaj lahko v master (t.j. v vejo v kateri se trenutno nahajate) zmixate prej ustvarjeno vejo z:


Git merge libreOffice

S tem ukazom ste vse spremembe, ki ste jih ustvarili v novi veji z imenom libreOffice zlili skupaj v default vejo (master).

Če hočete lahko sedaj pobrišete odrabljeno vejo z


Git branch -d libreOffice

Lahko pa jo seveda pustite pri meru za eventualno vrnitev?! Eh! niti ne 🙂

</Slovenian language>

Live templates for Android Studio 2 – Cheat sheet

Hello, my two visitors and hello Google crawler!

While this is my first post (and possibly the only one, unless some miracle happens) so I should introduce my self…
Nah! You can manage without it, I’m sure!

So this is it – short and …well…just short!

At the top are those live templates, that are most important to me personally – the rest follow later.

Loggers:


Log.d(TAG, String)

logd
android.util.Log.d(TAG, "$METHOD_NAME$: $content$");

Log.e(TAG, String, Exception)

loge

android.util.Log.e(TAG, "$METHOD_NAME$: $content$", $exception$);


Android:


Define android style int constant

const
private static final int $name$ = $value$;

Create a new Toast

Toast
android.widget.Toast.makeText(
$className$.this, "$text$"Toast.LENGTH_SHORT).show();

findViewById with cast

fbc
($cast$) findViewById(R.id.$resId$);

get a String from resources

rgS
$resources$.getString(R.string.$stringId$)

——–

Key for a bundle

key
private static final String KEY_$value$ = "$value$";

String format

Sfmt
String.format("$string$", $params$);

Create a for each loop

foreach
for ($i$ : $data$) {
$cursor$
}

Set view visibility to GONE

gone
$VIEW$.setVisibility(android.view.View.GONE);

Set view visibility to VISIBLE

visible
$VIEW$.setVisibility(View.VISIBLE);

Creates an Intent with ACTION_VIEW

IntentView
android.content.Intent view = new Intent();
view.setAction(Intent.ACTION_VIEW);
view.setData(android.net.Uri.parse($url$));
startActivity(view);

create a new Fragment instance with arguments

newInstance
public static $fragment$ newInstance($args$) {
$nullChecks$
android.os.Bundle args = new Bundle();
$addArgs$
$fragment$ fragment = new $fragment$();
fragment.setArguments(args);
return fragment;
}

private empty constructor to prohibit instance creation

noInstance
private $class$() {
//no instance}

runOnUIThread

rouiT
getActivity().runOnUiThread(new java.lang.Runnable() {
@Override
public void run() {
$cursor$
}
});

Creates a static start(…) helper method to start an Activity

starter
public static void start(android.content.Context context) {
android.content.Intent starter =
new Intent(context,
$ACTIVITY$.class);
    starter.putExtra($CURSOR$);    
context.startActivity(starter);
}

Adds generic view constructors

ViewConstructors
public $class$(android.content.Context context) {
this(context, null);
}
public $class$(Context context, android.util.AttributeSet attrs) {
this(context, attrs, 0);
}
public $class$(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);  
$cursor$
}

Git ‘vejenje’ (git branching)

Ker je za delo (tudi samostojno delo!) branching tako zelo uporabna metoda sem se odločil , da spišem tale kratek potek dela.
Teorija gre tako:
Programer se loti nekega spreminjanja kode za katerega pa ne ve, če bo sploh uporaben. Recimo, da hočete v vaš program dodati možnost izvoza podatkov v Libre Office.
Zato namesto da pišete v MASTER repo raje naredi novo vejo (branch), ki jo poimenuje po spremembi, ki jo želiote izvesti. Torej nekako tako:
Git checkout -b libreOffice
-b je za branch

V ukazni lupini boste zaznali spremembo:
namesto npr:
Hoornet@prostitute /c/Delo/MyWorkDir (master)
Bo sedaj 
Hoornet@prostitute /c/Delo/MyWorkDir (libreOffice)
Git vam tako sporoča na kateri veji se trenutno nahajate. Preskok je u šubu. Pri kreaciji nove veje to pomeni, da imate še vedno na voljo vso kodo od prej a lahko sedaj bolj ziheraško spreminjate kodo, saj manipulerate drugo vejo. V kateremkoli trenutku se lahko vrnete na prejšnje satanje.
Ko ste končali s ‘pod-projektom’ se odločite ali boste prelili spremembe v master ali ne. V primeru da je šlo vse ok delujte tako:
Najprej skočite nazaj na master z 
Git checkout  master
V trenutku boste nazaj v stanju pred vsemi spremmbami (t.j. v zadnjem stanju pred skokom v novo vejo). Sedaj lahko v master (t.j. v vejo v kateri se trenutno nahajate) zmixate prej ustvarjeno vejo z:
Git merge libreOffice
S tem ukazom ste vse spremembe, ki ste jih ustvarili v novi veji z imenom libreOffice zlili skupaj v default vejo (master).
Če hočete lahko sedaj pobrišete odrabljeno vejo z 
Git branch -d libreOffice
Lahko pa jo seveda pustite pri meru za eventualno vrnitev?! Eh! niti ne 🙂 Rape its ass out

1) Rails for assholes – kako slediti ‘projektu’ na github

Github.com 

ali 

“What the fuck he wants from us now?!?”

Premisa: ok. Recimo, da si len človek 🙂

In recimo, da si tok len, da se ti ne da brat vsega sranja, ki ga napišem v blog (totalno štekam, jest tud nebi bral. Kav si ta Hoornet sploh misle da je. Idiot debiln! Mah.. pustmo to…) in bi se predvsem rad naučil vsaj nekaj Rails programiranja (nice try asshole! You should be more clever and choose a different blog if you are serious. Don’t you see that Hoornet is just full of shit?!). Skratka zanima te predvsem koda…

Zato sem v svojem vsemogočnem, sočutju do tebe zastavil projekt (phahahaha! P… p… pr… projekt? hahaha) po delih. In to ne samo v obliki postov, ampak tudi v obliki paralelnih objav git tagov/branchov (whatever!) z imeni oz. številkami posta. Tako boš lahko (če bo seveda tale Hoornet sploh objavil naslednji post. Kreten!) preprosto sledil z do tistega trenutka narejenim projektom.
V ta namen bom uporabil že pridobljeno znanje (yeah right!) kontrole kode – GIT! Kot svoj server sem si izbral github, ki je za open source projekte (javne objave) đabe!!!

————–

 Postopek

Postopek?

Meh…

Tako imaš sedaj dve možnosti (poleg seveda tiste , da vso kodo preprosto pretipkaš sam. Ampak to ne paše pod zgornjo premisa, kajne? Hehe! Đerkl!):
1)
Vsakič posebej narediš mapo in za vsak moj git push narediš najprej:
 git clone https://github.com/Hoornet/hoornet_sample_app.git
nato po
 git checkout branch_veselega_idiota

ali pa (in to pot priporočam tudi osebno)

2)
a) se registriraš na github.com (itak ti zna prit tale site prav še v prihodnje. Je kratko malo the best on the market!)
b) greš na moj projekt: https://github.com/Hoornet/hoornet_sample_app in klikneš FORK the project. S tem, dobiš svojo kopijo.
c) To kopijo potem kloniraš na svoj comp podobno kot zgoraj (la da seveda s svojim naslovom). Nato pa jo (kodo) lahko poljubno manipuliraš, pushneš gor svoje spremembe, in ko jaz spremenim svojo kodo, lahko te spremembe tudi potegneš na svoj repo. Mal mogoče prebereš navodila na githubu pa bo.

———————–

Da pridobiš kod torej kloniraj (za naslov bom vedno uporabil svoj git naslov. Namesto njega lahko seveda uporabite svoj fork)

V izbrani mapi, kjer misliš voditi ta učni biser deluj tako:
git clone https://github.com/Hoornet/hoornet_sample_app.git

thats all folks! 

———————-

To je to za dons.
In? Pa drgač? Ti že kej pospuščajo živci? Je tvoja mazohistična duša zadovoljena z neprestanim žaljenjem? Če ne mi lahko napišeš pritožbo na:
janez.jansa@slo.gov.edo

Till next time…
asshole(s)….

0) Ruby on Rails for assholes (Ruby on Rails za kretene)

 Uvodnik

Če si želite, da vas nekdo zmerja in žali med tem ko se trudite učiti programiranja, potem ste prišli na pravo mesto!
Jaz, Hoornet, se bom posebej potrudil, da ti predam del znanja v skrajno nenavadni obliki. Zelo verjetno se ne boste naučili prav ničesar. V primeru da spravim v jok vsaj enega bralca bo moje delo opravljeno.
Zatorej pripravi svoj ego ščit in se odpravi na pustolovščino, ki pa se bo najbrž končala že danes saj se preveč len da bi napisal več kot nekaj vrstic na blog.
Moje ime je Hoornet in jaz sem znan po nesposobnosti!
Stopi v moj svet in postani neuporaben tudi sam!
In vseskozi si boš mislil da si se celo nekaj naučil! Ha! Zmota!

1) Inštaliraj Ruby on Rails

Oh, ti nesrečni človek, ki vstopaš v sobane kretena, uboga je tvoja glava.

Hoornet’s proverb (17. century)
 
Kaže,da bom neki klikal po knjigi Ruby on Rails Tutorial 3.2….
Inštalacija poteka tako:
Enostavno poinštaliraj RailsInstaller, ki ga najdeš na, hmmm, http://railsinstaller.org
Za vse nadaljno delo v command promptu uporabljaj “Command Prompt with Ruby and Rails”, ki ga najdeš pod Start->All programs->Railsinstaller

2) Ustvari sample_app

Najprej ustvari mapo kjer boš ustvaril rails app.
Sam uporabljam mapo RAILS za igranje s sabo 🙂
Do this:

D:GitHubFilesLearningRAILS>rails new sample_app -T
      create
      create  README.rdoc
      create  Rakefile
      create  config.ru

  [ Removed half a screen of this for reasons of sanity. ]

      create  vendor/assets/stylesheets/.gitkeep
      create  vendor/plugins
      create  vendor/plugins/.gitkeep
         run  bundle install
Fetching gem metadata from https://rubygems.org/...........
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies...
Using rake (10.0.3)
...Your buudle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

Komanda je več ali manj očitna. Edino kar je omembe vredno je

-T

Ta opcija namreč pomeni naj zgradi Rails app BREZ test direktorija.

Čas je za Git

Dragi (edini) bralec bloga!
Naj te danes napotim k neverjetno uporabnemu orodju modernega razvijalca programja. 

Uvodnik z malo zgodovine

Gre za enega najpopularnejših orodij za source control. Pred leti smo gonili CVS. Kasneje smo spoznali zmoto in naveliko preheblal na SVN oz. Subversion, kot smo mu pravili ljubkovalno. Delal je dost ql za tiste čase, če si seveda zadovoljen z nujno povezavo s serverjem za vsako dodano spremembo.
Ampak pred pa leti je popizdil The Linus!
Ja, taisti midel, ki je izumil Linux in ki se je dnevno zgražal nad grozljivim delom, ki ga je opravljal. In sicer gre za managing kode za Linux!
Si lahko predstavljaš vso kramo, ki jo ta model dnevo poriva v Linuxov repozitorij!
In ko model za nameček naleti na licenčne omejitve source control sistema, ki ga je takrat uporabljal je bila jeba popolna!
Tip popizdi in se dela loti sam, In v 14 dneh rukne ven eno začetno  verzijo SCM-ja z imenom Git!
Iskaže pa se fa je zadeva tok ql in tok hitra in univerzalna, da jo kmalu posvojijo tudi druge veje open source communitya.
Npr. Ruby folk! In ker zadnje čase Ruby kle gonmo je edino prav da tudi git posvojimo.

 Enouporabniško delo z Git (brez badaljnih nakladanj)

Ok. Nočeš torej vedeti zakaj je Git tak zakon itd. Zanima te zgolj kako začet z delom čimprej.
You’ve come to the right place, asshole!

Install the damn fence (i mean git)

Najprej seveda rabiš poinštalirat sam git. Go here, jerk! And look around for the download, won’t ya!
Windows idioti, kot jaz lahko grejo direkt na: http://git-scm.com/download/win
Ob času pisanja tega posta je bla vezija cca. 1.8.1
Skratka poinštaliraj git. Bili so časi, še nedavno tega (lani?) ko je bila inštalacija tega orodja malce zakomplicirana; prihajajoč iz Linuxa etc. Danes temu ni več tako. Predlagam pa da pokljukcate TrueType font, izberete “Run Git from win Command prompt” in drugo pustite pri meru. Če se odločite, da boste izbrali Easy verzijo, potem poklikajte še uni dve podopciji, t.j bash in Gui… 🙂

Prvi koraki…ali post inštalacija

Glede na to, da uporabljaš git prvič bi blo dobr povedat mu kdo za hudiča ti sploh si. To ti zna priti prav, ko bo treba kazati s prstom na druge, ko pride do zajbka v kodi:
“Kreten debiln od šefa! A ne vidiš kle! Kle ti kažem, kle, idiot! A ne vidiš kdo je podpisan pod commitom? A je to mogoče moje  ime? Prašam… Mislem sam rašam! A JE TO MOGOČE MOJE IME! Kaj piše kle?! Kle piše Janez Janša! A je men ime Janez Janša?
Ne! Men ni ime Janez Janša! In kaj piše kle? 
Kle piše Janez Janša!
Torej? Kdo je commitav ta del kode? 
A sm bil to jest?
Ne! To je bil Janez Janša!”
itd.
Skratka: There is enough blame to go arround 🙂
Pri vsakem commitu (to je zapisu stanja kode, kot je bilo v tistem trenutku) je zraven zapisan komentar avtorja commita in njegovo ime.
Do this:
$ git config --global user.name "Slovenec Brezkurcni"
$ git config --global user.email slovenec@brezkurcni.si
 

Zgornjo zadevo naklofaš v prompt samo enkrat, saj se zadeva (glej –global oznako) zapiše v tvoj user profil, nekje v .gitconfig dir.

Če hočeš prevert nastavitve do this:
git config --list

Ven bo vrgu neki podobnega kot:

core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
user.name=
Slovenec Brezkurcni
user.email=slovenec@brezkurcni.simerge.tool=kdiff3
mergetool.kdiff3.path=C:/Program Files/KDiff3/kdiff3.exe
diff.guitool=kdiff3
difftool.kdiff3.path=C:/Program Files/KDiff3/kdiff3.exe
difftool.kdiff3.cmd="C:/Program Files/KDiff3/kdiff3.exe" "$LOCAL" "$REMOTE"
core.editor="C:/Program Files/GitExtensions/GitExtensions.exe" fileeditor
core.autocrlf=true 

Seveda bo zadeva samo podobna. Zgornji izpis je bil izveden na kompu, ki ima zraven poinštaliran še
git extrension. Če ga hočeš ga maš kle, kjer si lahko kaj več o paketutudi prebereš.

Let’s init my …
Ok. Napredek! (če ti git ne dela c command promptu bi znalo bit dobr znova zagnat winse. Kaj češ, tehnologija prejšnjega tisočletja pač. Hehe. hehe. muahahhaha)
Do that:
1) 

 Start->All programs->Git->Git Bash

Evo ti slike:

2) Spizdi v mapo, katere vsebino (in struktoro) hočeš soravit pod verssion control (se sliš kot da ga daješ u jarem avtoritarne družbe). In ne pozabit da je bash, linux-like in ne windows-like (glej spodaj napako namesto / ):

Hoornet@HOORNET-PC ~
$ cd D:GitHubFilesBLOG
sh.exe”: cd: D:GitHubFilesBLOG: No such file or directory
Hoornet@HOORNET-PC ~
$ cd D:/GitHubFiles/BLOG
Hoornet@HOORNET-PC /d/GitHubFiles/BLOG
$

Ok. Torej recimo da sem v željeni mapi. Čist vseen je, ali je mapa prazna alin pa že ima vsebino. Ko namreč začenemo komando:

 $ git init
Initialized empty Git repository in d:/GitHubFiles/BLOG/.git/
Hoornet@HOORNET-PC /d/GitHubFiles/BLOG (master)
$

smo omenjeno mapo in vse podmape z vsebino vred postavili v source control. Seveda lahko ignoriramo določene mapi, fajle ali tipe fajlov ampak o tem (morda?) drugič.

Če sedaj damo pregledat kaj vse je v mapi, bomo videli, da je git dodal novo mapo z imenom:
.git

V tej mapi IN SAMO V TEJ MAPI je vse kar se tiče vaše pravkar init-ane mape in njene vsebine (dejmo zej temu pravt kar samo mapa. Nanaša se na vse podmape in svo vsebino v njih). Git nima svoje mape v vsakem poddirekltoruiju kot ste navajeni ustrahovani SVN-jevci. Totalni zakon, kadar hgočete skopširat vse kar mate v mapi brez gitovega dela!!!
Pa dejmo prevrit kva je sedaj not v mojem primeru.
3) Do this:

$ ls -a
.  ..  .git  Git_time
Hoornet@HOORNET-PC /d/GitHubFiles/BLOG (master)
$

Kot vidiš je poleg moje podmape git_time noter še en dir z imenom .git
Še nekaj! Skoraj vse to lahko počnete v običajnem win promptu ampak ne boste videli sprotne informacije kot je:

Hoornet@HOORNET-PC /d/GitHubFiles/BLOG (master)
$

In to: IN COLOR!!!! Že v letu 2013 e.v.!

4) Git vsebuje komando status, ki nam vedno poda trnutno sliko. Do that:
$ git status

in boš dobil izpoved:

# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use “git add” to track)
Hoornet@HOORNET-PC /d/GitHubFiles/BLOG (master)
$

Kot nam da sam git vedeti trenutno še ne sledimo ničemur. Dejmo nardit en ruby file s katerim se lahko potem igramo:

Za primer sem izbral en file (kontroller) iz Rails applikacije.

5) Torej dodajmo file v sledilnik (za drugačen prikaz bom sedaj uporabljal običajni Win command prompt). Najprej status potem dodajmo, rubijev file in nato še nkrat preverimo status:

D:GitHubFilesBLOG>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use “git add <file>…” to include in what will be committed)
#
#       Git_time/
nothing added to commit but untracked files present (use “git add” to track)

D:GitHubFilesBLOG>git add .

D:GitHubFilesBLOG>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use “git rm –cached <file>…” to unstage)
#
#       new file:   Git_time/movies_controller.rb
#

D:GitHubFilesBLOG>

Štekaš?
Sedaj mam now file noter namenjen sledenju, toda da zapišem trenutno stanje moram storiti še nekaj: Commit s komentarjem spremembe.
6) Do this:

 D:GitHubFilesBLOG>git commit -m”začetni commit”
[master (root-commit) 53192ac] začetni commit
 1 file changed, 60 insertions(+)
 create mode 100644 Git_time/movies_controller.rb

D:GitHubFilesBLOG>

Če sedaj poizvem po statusu sledenih datotek dobim sledeč rezultat:

D:GitHubFilesBLOG>git status
# On branch master
nothing to commit, working directory clean

D:GitHubFilesBLOG>

Vse datoteke so torej shranjene v trenutnem stanju. Dajmo sedaj spremenit datoteko tako, da bom pobrisal 3 metode v fajlu:  


Preverimo sedaj status, da vidimo, če je git poštekal da sem premenil fajl:
D:GitHubFilesBLOG>git status
# On branch master
# Changes not staged for commit:
#   (use “git add <file>…” to update what will be committed)
#   (use “git checkout — <file>…” to discard changes in working directory)
#
#       modified:   Git_time/movies_controller.rb
#
no changes added to commit (use “git add” and/or “git commit -a”)

Aha! Git je zaznal spremembo. Recimo da smo sedaj vmes programirali in da je sedaj ta datoteka končana. Torej je čas za nov commit.  Postopek, ki ga nato ponavljam ob vsaki spremmbi, ki jo ohčem zapisati je:

D:GitHubFilesBLOG>git add .

D:GitHubFilesBLOG>git commit -m”odstranil odvečne metode”
[master f6f5754] odstranil odvečne metode
 1 file changed, 21 insertions(+), 60 deletions(-)
 rewrite Git_time/movies_controller.rb (82%)

D:GitHubFilesBLOG>

Na tak način imam zapisane vse verzije vseh fajlov in map.
O tem kako do dolečene verzije pa (morda) prihodnjič.

Za zdaj lahko rečem samo to:
Switch to git!

C ya!