{"id":27404531,"url":"https://github.com/lorenzocorbella74/gitcommands","last_synced_at":"2025-10-06T19:05:35.659Z","repository":{"id":122249027,"uuid":"85596269","full_name":"LorenzoCorbella74/gitCommands","owner":"LorenzoCorbella74","description":"My personal git \u0026 gitflow cheat sheet","archived":false,"fork":false,"pushed_at":"2018-09-10T14:30:30.000Z","size":172,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-04-14T05:41:49.770Z","etag":null,"topics":["git","workflow"],"latest_commit_sha":null,"homepage":"","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/LorenzoCorbella74.png","metadata":{"files":{"readme":"Readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2017-03-20T15:51:28.000Z","updated_at":"2018-09-10T14:30:31.000Z","dependencies_parsed_at":"2023-03-12T00:30:15.063Z","dependency_job_id":null,"html_url":"https://github.com/LorenzoCorbella74/gitCommands","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/LorenzoCorbella74/gitCommands","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LorenzoCorbella74%2FgitCommands","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LorenzoCorbella74%2FgitCommands/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LorenzoCorbella74%2FgitCommands/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LorenzoCorbella74%2FgitCommands/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/LorenzoCorbella74","download_url":"https://codeload.github.com/LorenzoCorbella74/gitCommands/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LorenzoCorbella74%2FgitCommands/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":278663361,"owners_count":26024388,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-06T02:00:05.630Z","response_time":65,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["git","workflow"],"created_at":"2025-04-14T05:39:09.306Z","updated_at":"2025-10-06T19:05:35.647Z","avatar_url":"https://github.com/LorenzoCorbella74.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"# GIT: Principali comandi ed esempi di workflow\n\n## Table of Contents\n - [Utilities](#utilities)\n - [Impostazioni globali](#impostazioni-globali)\n - [Creare Repository](#creare-repository)\n - [Modifiche locali](#modifiche-locali)\n - [Tag](#tag)\n - [Commit history](#commit-history)\n - [Differenze](#differenze)\n - [Branch](#branch)\n - [Update and Publish](#update-and-publish)\n - [Merge Rebase](#merge-rebase)\n - [Stash](#stash)\n - [Conflicts](#conflicts)\n - [Undo](#undo)\n - [Comandi avanzati alias](#comandi-avanzati-alias)\n - [Gitflow](gitflow.md)\n\n## Utilities\n- Apre il browser con il readme di aiuto del comando specificato:  ` $  git nomecomando --help`\n- Cerca nella working directory il testo 'pippo'  `$ git grep \"pippo\"`\n- per pulire la finestra: ` $ git clean // -fd per forzare il cleaning`\n- per avere tutti i riferimenti ai commit (anche quelli cancellati): ` $ git reflog`\n\n## Impostazioni globali\nPer settare l'utente e relativa email:\n```\n    \u003e git config --global user.name \"Lorenzo Corbella\"\n    \u003e git config --global user.email \"l.corbella@dstech.it\"\n```\nPer vedere la lista dei parametri di configurazione: ` \u003e git config --list`\n\n## Creare Repository\n- Creare un repository locale: ` $  git init`\n- Clonare un repository remoto esistente. Il comando `clone` di fatto crea una nuova directory, stabilisce un 'upstream remote traking' con un repository remoto, fa il checkout sul branch attivo e riproduce in locale una copia completa della storia dei commit di un repository:  ` $  git clone https://github.com/Lorenzo74/gitCommands.git `\n- Clonare branch specifici su github:\n```\n    // per clonare solo un branch specifico\n    $  git branch -a // mostra tutti i branch presenti su remote\n    $  git checkout -b nomebranch origin/nomebranch // scarica il branch nomebranch \n    // per avere tutti i branch di un repository\n    $ mkdir mydir $  cd mydir\n    $ git clone --mirror https://github.com/Lorenzo74/gitCommands.git .git \n    $ git config --bool  core.bare false \n    $ git reset --hard  \n    // per usare un branch come template\n    $ git clone -b brachchevogliocopiare https://github.com/Lorenzo74/gitCommands.git\n```\n[Go to top](#table-of-contents)\n\n## Modifiche locali\n- Verificare cosa è successo dall'ultimo commit:`$  git status`\n- Aggiungere il file indicato, modificato rispetto all'ultimo commit, nello STAGE: `$  git add index.html`\n- Aggiungere tutti i file modificati nello STAGE (l'eventuale flag -p richiede di confermare ogni singola modifica): `$  git add .`\n- Rimuovere il file, precedentemente aggiunto, dallo STAGE, ma mantenendo le modifiche: `$  git reset-- index.html` o `git reset -q HEAD -- index.html`\n- Committare i file indica salvare uno snapshot dello stage. Git committerà soltanto cambiamenti nello stage(index) e non i cambiamenti nella working directory. Git ragione per cambiamenti pertanto ogni commit ha un riferimento al proprio padre: `  $  git commit -m \"Messaggio del commit\"` . Il flag `-am` committa direttamente i file modificati dalla working area all'HEAD senza passare dallo stage.\n\n- Se si è dimenticato qualcosa dall'ultimo commit, combinare i file nello stage e l'ultimo commit (creando nella history un nuovo commit): `  $  git commit --amend -m \"New commit message `. Se non aggiungo il commento si apre un editor e posso modificare il commento. Con 'amend' cambia lo SHA dell'ultimo commit. Oppure `  $  git add .` e poi `  $  git commit --amend`, e poi su VIM premere ESC poi ':wq' e poi return\n- Per vedere i dettagli di un commit:  `  $  git show 65476fa ` oppure  `  $  git show nome_tag `\n\n## Tag\nI 'tag' rappresentano dei bookmark 'personali' dei commit locali. \n- per avere una lista dei tag: `\u003e git tag`\n- Per marcare il commit corrente con un tag e poterlo in seguito confrontare con altri commit `$  git tag v1.0` \n- si taggare uno specifico commit si usa lo SHA: `  $  git tag nome_tag 4b8e1ad`.\n- tramite flag -a si ottiene un tag annotato, (git apre un editor per inserire un msg): `$  git tag -a nome_tag 4b8e1ad`.\n- per cancellare un tag: `  $  git tag -d nome_tag`.\n\nNB: Per poi visionare un commit taggato si usa: `$ git show nome_tag` ma è più utile andare ad uno specifico punto del repository tramite `$ git checkout nome_tag`. in tale caso si entra nel `detached HEAD state`e si possono fare esperiementi o modifiche (per rimuoverle si usa `\u003e git checkout -- nomefile`   metre per aggiungerle si deve fare un nuovo branch con `\u003e git chechout -b nomebranch`).\n\n- per condividere i tag in remoto si deve usare:  `  $  git push --tag nome_remote`.\n\n### Esempio: workflow semplice\n- Si crea una directory con `mkdir nomedir $  cd nomeDir`\n- Si crea inizializza un progetto con git `$ git init`\n- Si crea un file di readme con `$ copy con newFile ` oppure su linux `$ touch newFile`\n- Si aggiunge il readme allo stage `$ git add newFile `\n- Si crea uno snaphot delle modifiche con `$ git commit -m \"newFile added\" `\n- Si guarda l'history delle modifiche con `$ git log `\n\n[Go to top](#table-of-contents)\n\n## Log: Commit history\n- Mostra l'hash, l'autore e la data di tutti i commit partendo dal primo:  ` $  git log`\n- Mostra le modifiche nel tempo di un unico file:  ` $  git log -p index.html`\n- Mostra le modifiche ancora non incluse nel branch attuale rispetto a master:  ` $  git log ..master`\n- Mostra chi ha cambiato, cosa e quando di un unico file:  ` $  git b lame index.html`\n- Il flag `--stat` mostra l'hash, l'autore, la data e una sintesi dei file modificati, `--oneline` produce righe con hash e il msg del commit, mentre `--decorate` indica anche il branch e i tag, `--graph` disegna un grafico indicante il commit history, `--all` mostra tutti i commit. Si può formattare il log con `--pretty=format:\"%cn committed %h on %cd\"` o filtrare la commit history per data `git log --after=\"2014-7-1\" --before=\"2014-7-4\"` o per autore `git log --author=\"John\"`, il flag `-n10` mostra gli ultimi 10 commit. \n- ` $ git shortlog` riporta una lista dei commit suddivisi per autore.\n\n[Go to top](#table-of-contents)\n\n## Differenze\n- Mostra le differenze tra lo Stage e la working directory:  ` $  git diff  `\n- Mostra le differenze tra l'HEAD e lo Stage:  ` $  git diff --staged `\n- Mostra l’elenco delle modifiche che devo applicare a `from` perché il progetto diventi identico a quello fotografato in `to`:  ` $  git diff from to  `\n- Mostra le differenze tra due commit: `$  git diff 65476fa 4b8e1ad `\n- Mostra le differenze su un file/ cartella: `git diff nomebranchdaconfrontareconilcorrente -- apps\\widgets\\nomecartella`\n- Mostra le differenze incluse tra due commit(il + recente prima, il + vecchio dopo): `$  git diff 65476fa..4b8e1ad `\n- Mostrare le differenze tra due branch: `git diff branch_sorgente branch_target`\n- Mostrare le differenze tra un tag e la working directory (il flag --stat indica un resoconto dei cambiamenti): `git diff v1.0`\n- Mostrare un resoconto tra due branch:  `git diff --stat nomebranch1 nomebranch2`\n\n[Go to top](#table-of-contents)\n\n## Branch\nOgni qual volta si inizia una nuova feature, bugfix, o esperimento si deve creare un nuovo branch che sono dei semplici puntatori a commit, delle 'etichette' (nei trasizionali VCS invece sono di solito delle copie dei working files).\n- Mostrare tutti i branch correnti:  `$  git branch -av `\n- Per switchare ad un branch specifico:  `$  git checkout nomebranch `\n- Creare un nuovo branch basato sull'ultimo commit (HEAD):  `$  git branch nomebranch`\n- Crea un nuovo-branch e passa al nuovo branch:  `$  git checkout -b nuovo-branch`\n- Crea un nuovo-branch e passa al nuovo branch partendo da dev:  `$  git checkout -b nuovo-branch dev`\n- Creare un nuovo branch basato su un brach remoto:  `$  git checkout --track path/remote/branch `\n- Cancellare un branch locale:  `$  git branch -d nomebranch `\n- Cancellare un branch remoto:  `$  git branch -dr remote/branch`\n- Il branch non sarà disponibile agli altri fino a quando non verrà inviato al repository remoto  `$ git push -u remote(origin) local-branch // -u sta per 'upstream`\n\n[Go to top](#table-of-contents)\n\n## Update and Publish\n### Repository remoti\nIl comando 'pull' è di fatto uno shortcut per 'fetch' seguito da 'merge' e può scaricare l'intero repository o uno specifico branch. Pushiare dei cambiamenti richiede prima che venga fatto un pull: questa azione può portare a dei conflitti nel merge, in quanto altri developer possono avere aggiornato file specifici prima di noi.\n```\n    $ git remote -v     // dà la lista dedi repository remoti\n    $ git remote show https://gitlab.cloud.net/ApplicationSkeleton  // mostra informazioni del remote corrente\n    $ git remote add nomebranch https://gitlab.cloud.net/nomebranch // aggiungi un repository remoto indicando il nome e l'URL e attivando il 'traking' di tale repository\n    $ git remote rm nomebranch  // rimuove un repository remoto indicando il nome \n\n    $ git fetch nomeremote // scarica tutte le modifiche da nomeremote ma non le integra nell'HEAD\n    $ git pull nomeremote // scarica tutte le modifiche da nomeremote e le integra mergiandole nell'HEAD\n    $ git push nomeremote nomebranch  // pubblica le modifiche locali sul remoto\n```\n\nQuando si lavora con un repository condiviso è possibile vedersi rigettare un push in quanto altri hanno modifiche più recenti ai file nella local history. E' possibile risolvere con: ` git pull --rebase` e poi `git push origin/master`.\n\n[Go to top](#table-of-contents)\n\n## Merge \u0026 Rebase\nIn GIT ci sono due modi per integrare i cambiamenti da un ramo all'altro: `MERGE` e `REBASE`.\n\n### Merge\nIl comando merge crea un nuovo commit che include le modifiche provenienti da un commit contenente tutte le modifiche del branch di destinazione e un commit con tutte le modifiche del ramo di origine. E' un commit avente due padri. Si dice che si mergia il ramo di origine delle modifiche nel ramo di destinazione.\n```\n    $ git chechout master // si va nel ramo che riceverà (ramo di destinazione)\n    $ git merge branch-to-integrate // si specifica da chi prendere i commit (ramo di origine)\n```\nNel caso in cui si vogli accorpare durante il merge tutti i commit del feature branch bugfix in un commit:\n```\ngit checkout master\ngit merge --squash bugfix\ngit commit\n```\n\n### Rebase (Rifondazione) - rewriting history\n![rebase](img/rebase.png)\n\nIl comando rebase è particolarmente utilizzato per:\n\n- spostare il ramo featurebranch all'estremità del master e tutti i commit di questo vengono inclusi nel ramo di destinazione. Si ha così una rifondazione della cronologia del featurebranch. Se il merge crea un singolo commit con due genitori preservando l'history non lineare, un rebase riporta i commit dal branch corrente su un altro producendo una history lineare. E' un modo automatizzato di eseguire in sequenza diversi cherry-pick.\n```\n    $ git chechout featurebranch     // si va nel ramo che vogliamo muovere\n    $ git rebase branch-to-integrate // si specifica il nome del branch che ha i commit che voglio integrare nel mio featurebranch\n```\n- Combinare insieme diversi commit:\n- troncare un branch prima di mergiarlo con git mege --no-ff nomebranch_troncato\n- combinare i cambiamenti in un altro branch\n- cambiare i precedenti commit (con un rebase interattivo)\n```\n    $ git rebase -i 3gt56er9  (o git rebase -i HEAD~4 per tornare indietro di 4)\n```\nPer il rebase interattivo si specifica il 1° commit precedente a quello da cui si vuole partire per poi applicare sui successivi delle operazioni ('pick' tiene il commit, 'swash' per combinarlo con il precedente tenendo il message). Si può modificare l'ordine e cancellare dei commit, rimuovendo semplicemente la riga: git poi aprirà l'editor per poi modificare i commenti dei commi risultanti (wq per chiudere l'editor).\n\n### Cherry Pick\nPer copiare un commit da un branch ad un altro si utilizza il comando cherry-pick. Il comando copia un commit creandone uno nuovo nel branch corrente con lo stesso msg dell'originale applicando le modifiche come se fosse un commit diverso: `  $ git cherry-pick 65476fa`\nIl comando può essere utile in molti casi come ad esempio per correggere un bug a metà di un ramo: in questa situazione si deve tornare indietro nel tempo e riapplicare tutti i commit corretti tranne quello che ha generato il bug:\n```\n    git checkout master\n    git branch --force feature\n    git checkout feature\n    git cherry-pick b5041f3\n    git cherry-pick 8f41bb8\n```\nCherry-pick si comporta proprio come `merge`. Se git non può applicare le modifiche per conflitti ti richiede di risolverli e di fare il commit manualmente.\n\n[Go to top](#table-of-contents)\n\n## Stash\nSiamo nel mezzo dello sviluppo di qualche funzionalità, ma emerge la necessità di interrompere tutto per dedicarsi al bugfix sul commit precedente: non si può perdere il lavoro non committato e si accantona il codice non committatato (lo stato della working directory e dell'index) e si ritorna allo stato dell'ultimo commit con uno stato pulito della working directory.\n```\n    $ git stash -a \"nomeStash\"     // -a permette di dare un nome all'accantonamento\n    $ git stash list               // elenca una coda di stash\n    $ git stash apply              // quando si è pronti a ritornare da dove si era lasciato il comando riporta indietro ai cambiamenti fatti nella working directory\n    $ git stash pop                // uguale a apply ma rimuove lo stato dallo stash list\n    $ git stash drop [stash_ref]   // rimuove l'ultimo stash\n    $ git stash clear              // pulisce la lista di stash\n    $ git stash branch testchanges // crea un branch da uno stash\n```\n[Go to top](#table-of-contents)\n\n## Conflicts\nPer risolvere i conflitti si utilizzano vari tool. Per incorporare un altro branch nel branch attivo si utilizza `$ git merge nomebranch`, e git prova ad auto-incorporare le modifiche. Sfortunatamente, a volte questa procedura automatizzata non è possibile, ed in questo caso ci saranno dei conflitti che dovranno essere sistemati manualmente modificando i file che git mostrerà. Dopo aver cambiato questi files, si devono marcare come 'correttamente incorporati' tramite 'git add nomedelfileeditato' e poi committare le modifiche/il merge.\n```\n    \u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c HEAD indica ciò che è contenuto nel branch corrente\n\n    ========= separatore\n\n    \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e nomedelbranch\n\n     $ git mergetool    // usa il tool configurato per risolvere i conflitti\n     $ git diff branch_sorgente branch_target\n     $ git add resolved-file   // marcare i file  risolti manualmente\n     $ git commit              // committare i cambiamenti del merge\n```\n[Go to top](#table-of-contents)\n\n## Undo\nPer vedere temporaneamente un commit \"spostandosi nel tempo\":\n```\n    $ git checkout 65476fa \n    $ git checkout 65476fa index.html // per vedere temporanemante solo un file\n    $ git checkout master             // per tornare allo stato “current” del progetto\n```\nQuando ci si muove tra i commit, git avvisa che non si è attaccati ad un branch per cui qualsiasi modifica non avrà impatto sulla posizione di alcun branch (e suggerisce anche di crearne uno col comando git checkout -b): HEAD sta puntando direttamente al commit e non ad un branch. Lo stato in cui HEAD non punta ad un branch viene chiamato `detached head` e si è rimossi dalla history dei commit.\n\nDa notare che se modifico dei file ma non li aggiungo all'index una volta che faccio il checkout ad un certo commit git riporta un errore dicendo che le modifiche locali sarebbero sovrascritte dal checkout e che è richiesto di committare le modifiche o fare uno stash.\n\n### reset \nIl comando `reset` cambia dove il branch corrente punta. Elimina le modifiche locali nella working directory e nell'index, ritornando all'ultimo committed state (non è da usare in un repository condiviso con commit pushiati da altri...)\n```\n$ git reset --hard HEAD // HEAD si può omettere sta per branch corrente\n```\nIl flag ` --hard ` aggiorna la working area facendola combaciare con l'index, in altre parole ogni modifica presente nella working area locale non saranno preservate. Fare l'undo dell'ultimo commit è svolto con: `$ git reset --soft HEAD~1`.\nUn possibile scenario potrebbe essere, si è fatto un commit non pushiato sul remoto, poi si decide di rimuoverlo con `git reset`, modificando la storia come se non fosse mai esistito.\n\n### checkout\nIl comando checkout prende il commit indicato e lo copia nel file system e nella staging area, e non si hanno modifiche alla commit history. Nel caso si abbia qualcosa di sbagliato si può sostituire i cambiamenti fatti in locale, non ancora committati,  con il comando `git checkout -- nomedelfile` o `git checkout -- .` questo rimpiazza le modifiche nella working area con l'ultimo contenuto presente in HEAD. I cambiamenti fatti ed aggiunti all'index, così come i nuovi files, verranno mantenuti. La differenza fondamentale tra `reset` e `checkout` sta in come l'index è interessato dai due comandi: `checkout` ripristina la working directory allo stato del commit, i file sono aggiunti e rimossi), mentre nel reset è come se i commit non fossero mai esistiti.\nUn possibile scenario potrebbe essere mettere dei file modificati nell'index senza committarli. Tramite `git checkout` si riottiene una working area pulita ma con l'index ancora presente.\n\n### revert\nE' possibile inoltre fare un revert del commit (producendo un nuovo commit con modifiche opposte, si cancella quindi commit pubblicati con nuovi commit che prevengono la perdita della commit history. E' utile quando un commit ha introdotto dei bug che possono essere rimossi facendo il revert delle modifiche in precedenza applicate. E' la modalità di UNDO considerata + sicura.\n```\n    $ git revert 65476fa\n    $ git revert HEAD~2..HEAD // fa il revert degli ultimi due commit\n```\n\nRitornare indietro al commit indicato, modificando l'history dei commit.\n```\n    $ git reset --hard 65476fa  // ...elimina le modifiche locali nella working directory\n    $ git reset  65476fa        // ...preserva le modifiche dei commit successivi a quello indicato e messi come unstaged\n    $ git reset HEAD readme.md  \n    // cancella le modifiche aggiunte allo stage e ripristina il file alla versione dell'ultimo commit (poi dovrà essere fatto git checkout -- readme.md per tornare insietro all'ultimo stato pulito...)\n    $ git reset --keep 65476fa // ...e preserva modifiche locali non committate.\n\n    // If I want to keep the last changes...\n    $ git stash -a \"feature\"\n    $ git reset --hard 65476fa\n    $ git stash apply \"feature\"\n```\n\n[Go to top](#table-of-contents)\n\n## Comandi avanzati alias\n\nGli alias sono contenuti in una sezione dedicata dei settings:\n\n` \u003e cat .git/config | grep -A 1 \"\\[alias\\]\"`\n\nUtilizzando gli alias è possibile semplificare i comandi di git impartiti da terminale (quelli globali, quelli del progetto attuale etc):\n\n- shorthand del git status: \n` \u003e git config --global alias.st status --short --branch` o `-sb`\n\n- shorthand per committare tutti i file modificati:\n` \u003e git config --global alias.cma \"commit --all -m\"`\n\n- shorthand per quick merge: si lavora in un branch e poi si mergia in master con l'unione di due comandi:\n` \u003e git config --global alias.qm '!git checkout $1; git merge @{-1}'` si usa con: \n` \u003e git qm master`\n\n- shorthand per il log:\n` \u003e git log --pretty='%h | %d %s (%cr) [%au]`\n\n` \u003e git log --pretty='%Cred%h%Creset | %C(yellow)%d%Creset %Cgreen%s%Creset (%C(cyan)%cr%Creset) %Cred[%au]%Creset --graph --all`\n\n` \u003e git config --global alias.lg \"log --pretty='%Cred%h%Creset | %C(yellow)%d%Creset %Cgreen%s%Creset (%C(cyan)%cr%Creset) %Cred[%au]%Creset --graph --all\"`\n\n- shorthand per git diff:\n` \u003e git config --global core.pager 'less -RFX' `\n` \u003e git config --global alias.dp 'diff --word-diff --unified=10 --histogram' `\n\n[Go to top](#table-of-contents)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Florenzocorbella74%2Fgitcommands","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Florenzocorbella74%2Fgitcommands","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Florenzocorbella74%2Fgitcommands/lists"}