Da principiante a esperto di GitHub: una guida completa

Se vuoi guadagnare con GitHub, il percorso più diretto non è complicato: a condizione che la licenza lo permetta, trova progetti open-source di valore, trasforma il deployment, la documentazione in italiano e l'assistenza post-vendita in un servizio, e vendi la consegna su piattaforme come Xianyu.

Tuttavia, ciò che fa davvero guadagnare è la capacità di filtrare le informazioni e di implementare. Se vuoi fare AI, passare a FDE (Full-stack Development Engineer), o trasformarti in una OPC (One Person Company), il codice, la documentazione, le versioni e la collaborazione finiranno prima o poi su GitHub.

Anche se ti dedichi alla creazione di contenuti o ai social media, su GitHub ci sono un gran numero di strumenti per la scelta degli argomenti, progetti di automazione e processi di produzione di contenuti. Una volta che i file aumentano e l'AI apporta modifiche, senza Git per gestire le versioni, le cose sfuggiranno rapidamente di mano. Pertanto, i programmatori devono impararlo, così come i project manager e i creatori di contenuti; determina se puoi trasformare un'idea in un progetto gestibile, riutilizzabile e consegnabile.

Ho passato più di due settimane a perfezionare questo articolo, praticando Git, GitHub, Commit, branch, PR ed errori comuni da 0 a 1. Le future dirette seguiranno questo stesso processo. Prima della trasmissione ufficiale, rendo pubblico questo tutorial. Puoi salvarlo nei preferiti o seguirlo completamente.

1. Git e GitHub: Chi Gestisce Cosa?

Git è uno strumento di gestione delle versioni installato sul tuo computer. Quando sei offline, puoi comunque eseguire commit, visualizzare la cronologia, creare branch e fare merge. GitHub è una piattaforma di repository remota e collaborazione; riceve i commit inviati da Git e fornisce Issues, Pull Requests, Actions, revisioni del codice e gestione dei permessi.

La cosa più facile da confondere in Git è che la stessa modifica può esistere in quattro posizioni diverse. L'infografica qui sotto suddivide l'area di lavoro, l'area di staging, il repository locale e il repository remoto in quattro livelli.

Premere "salva" scrive solo il contenuto sul disco rigido. git add si occupa della selezione, git commit lascia una versione in locale e git push invia questi commit a GitHub.

Quindi, prima di eseguire il commit, controlla il diff, esegui o testa; dopo aver inviato con successo, torna alla pagina web per un doppio controllo. In questo modo, se si verifica un problema, puoi immediatamente sapere a quale livello si è fermato.

2. Prima di Iniziare: Prepara Solo Quattro Cose

Hai bisogno di Git, un account GitHub, un editor e un progetto su cui fare pratica. VS Code è sufficiente come editor, e il progetto può essere una pagina web o un documento Markdown.

Per prima cosa, conferma Git nel terminale:

1git --version

Questo esercizio utilizza macOS e Git 2.49.0. Gli utenti Windows possono usare Git Bash o il terminale integrato di VS Code; i comandi Git qui sotto sono gli stessi.

Successivamente, configura l'autore del commit:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

Queste sono le informazioni sull'autore scritte nel record del commit; non servono per accedere a GitHub. Se vuoi configurarlo solo per il progetto di pratica corrente, sostituisci --global con --local.

L'accesso a GitHub è una cosa separata. La riga di comando utilizza comunemente tre metodi:

• GitHub CLI, autorizzando tramite browser con gh auth login;
• HTTPS, utilizzando un Personal Access Token o un gestore di credenziali;
• SSH, aggiungendo una chiave pubblica a GitHub e autenticandoti tramite chiave in seguito.

I principianti possono scegliere GitHub CLI o HTTPS. Quando usi HTTPS, se il terminale chiede una Password, inserisci il Token; le normali password degli account non sono più valide. Non scrivere il Token nei comandi, negli URL remoti, nei README, nelle chat o negli screenshot.

3. Non Affrettarti con init: Conferma Dove si Trova Effettivamente il Terminale

Questo esercizio inizia con una semplice pagina web. Può essere aperta in un browser ma non ha ancora una cronologia Git.

Ci sono tre file nel progetto:

1index.html
2style.css
3.gitignore

In VS Code, seleziona "Apri cartella", non fare clic su un singolo file HTML. Quindi esegui nel terminale integrato:

1pwd
2ls

pwd mostra la directory corrente, e ls elenca i file. Continua solo dopo aver visto index.html e style.css.

Questo controllo sembra sciocco, ma previene il tipo di incidente più problematico: qualcuno che esegue git init sul Desktop, in Documenti o persino nella home directory dell'utente, e poi git add . che mette migliaia di file irrilevanti nell'area di staging. Git non è rotto; la directory era sbagliata.

4. Cosa Fa git init?

Ora inizializza il repository:

1git init -b main
2git status --short

git init -b main crea una directory .git nella cartella corrente e nomina il branch iniziale main. .git è una directory nascosta dove vengono memorizzate informazioni come commit, branch, area di staging e indirizzi remoti. I file del progetto rimangono al loro posto; Git inizia ad osservarli da questo momento.

Il ?? nello screenshot indica file non tracciati. I file esistono, ma Git non ha ancora deciso se registrarli.

Per confermare la directory radice del repository, puoi eseguire:

1git rev-parse --show-toplevel

L'output dovrebbe essere la cartella del progetto corrente. Se dice fatal: not a git repository, controlla prima la directory, poi verifica se git init è stato eseguito.

5. Il Primo Commit: Mantieni un Punto di Partenza Affidabile

Il progetto non è stato ancora modificato, quindi perché eseguire prima il commit? Perché tutte le modifiche successive hanno bisogno di un punto di partenza confrontabile. Per prima cosa, apri la pagina web in un browser per confermare che il titolo, le card e l'area di registrazione siano visualizzati; restringi la finestra per vedere se c'è scorrimento orizzontale a larghezza mobile.

Poi guarda .gitignore. Il contenuto utilizzato questa volta è:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore serve per bloccare chiavi, log, dipendenze e artefatti di build. Funziona principalmente su file non ancora tracciati. Se una chiave è già stata committata e poi la aggiungi a .gitignore, quella cronologia esiste ancora; la gestione corretta include anche la revoca o la rotazione della chiave.

Inizia a selezionare i file per il primo commit:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

La A nello stato sta per Added (Aggiunto), indicando che il file è entrato nell'area di staging. git diff --cached --stat ti dirà quanti file ti stai preparando a committare e approssimativamente quante righe sono state modificate. Per vedere il contenuto specifico, esegui:

1git diff --cached

Esegui il commit dopo la conferma:

1git commit -m "chore: Inizializza pagina reclutamento AI campus"
2git log --oneline
3git status

Un Commit può essere inteso come un'istantanea del progetto con autore, ora, descrizione e commit padre. ffdf4ff è la versione breve di questo hash di commit; usarlo nel repository corrente può individuare con precisione la versione.

feat, fix, docs, style, chore sono tipi di commit comuni, non una sintassi Git obbligatoria. Più importante del prefisso è la descrizione in italiano (o inglese) che segue: cosa è stato fatto, quale oggetto è stato modificato e perché.

6. Il Secondo Commit: Tratta le Modifiche dell'AI come Bozze da Revisionare

Successivamente, aggiungi un pulsante "Visualizza metodo di registrazione" alla pagina. Quando uso strumenti di programmazione AI, scrivo i confini nel prompt:

1Modifica solo index.html, aggiungi un link "Visualizza metodo di registrazione" sotto il testo introduttivo,
2che colleghi a #apply all'interno della pagina. Non modificare style.css, non eseguire commit Git.
3Al termine, dimmi quale file è stato modificato.

Anche la modifica manuale è semplice:

1<a class="cta" href="#apply">Visualizza metodo di registrazione</a>

L'AI dice di aver finito, ma non eseguire ancora il commit. Esegui:

1git status --short
2git diff -- index.html
3git diff --check

git diff mostra le modifiche nell'area di lavoro che non sono state ancora messe in staging. Il + verde è una riga aggiunta, il - rosso è una riga eliminata. git diff --check non ha output, indicando che non sono stati trovati problemi di formattazione evidenti come spazi finali; non controllerà per te se il pulsante è cliccabile.

Torna al browser e aggiorna, fai clic sul pulsante, poi restringi la finestra. La pagina dovrebbe scorrere fino all'area di registrazione, e il pulsante e le card dovrebbero essere ancora normali su schermi stretti.

Esegui il commit solo dopo che il test è superato:

1git add index.html
2git diff --cached
3git commit -m "feat: Aggiungi voce di registrazione per visualizzare rapidamente i metodi di candidatura"
4git log --oneline -2

A questo punto, ci sono due versioni chiare nel repository: la pagina iniziale e il pulsante di registrazione. Se il pulsante ha problemi in seguito, puoi trovare direttamente quale commit lo ha aggiunto.

A proposito, distingui i due diff:

1git diff             # Differenza tra area di lavoro e area di staging
2git diff --cached    # Differenza tra area di staging e commit più recente

Se git diff non ha output, il file potrebbe non essere stato salvato, oppure potrebbe essere già stato messo in staging o committato. Controllare git status, git diff --cached e git log in sequenza è più affidabile che digitare ripetutamente git add ..

7. Branch: Lascia uno Spazio di Test per le Modifiche Incerte

Il pulsante aggiunge solo una riga, quindi il rischio è piccolo. Cambiare l'intero tema da viola ad arancione potrebbe essere bello o potrebbe essere pacchiano; questo tipo di modifica è adatto per un branch.

1git switch -c experiment/warm-theme
2git branch --show-current

Un branch è concettualmente un nome che punta a un certo commit. Quando un nuovo branch viene creato per la prima volta, punta allo stesso commit di main, quindi i file sono esattamente gli stessi. Solo quando il branch sperimentale genera nuovi commit le due linee divergono.

Nel diagramma, il main blu punta ancora al secondo commit, mentre l'experiment arancione punta già al terzo commit. Il progetto non ha duplicato due serie di file; sono cambiati solo i puntatori per i due nomi di branch.

Modifica le variabili di colore in style.css, aggiorna la pagina per confermare, poi esegui il commit:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Prova tema caldo nel branch sperimentale"
5git log --oneline --graph --decorate --all

HEAD indica dove ti trovi attualmente. Nello screenshot, HEAD punta a experiment/warm-theme, mentre main rimane al commit del pulsante.

Decidi di mantenere il tema caldo, torna a main e fai il merge:

1git switch main
2git merge experiment/warm-theme

Qui si verifica un Fast-forward perché main non ha avuto nuovi commit durante l'esperimento. Git sposta direttamente il puntatore di main in avanti al commit del tema caldo; le modifiche sono state unite con successo.

I branch uniti possono essere eliminati in sicurezza:

1git branch -d experiment/warm-theme

La -d minuscola controlla se il branch è stato unito. La -D maiuscola forza l'eliminazione, e i commit nel branch che non sono stati uniti potrebbero perdere i loro riferimenti; non usarla come comando di pulizia quotidiana.

8. I Conflitti Non Sono Misteriosi; Git Semplicemente Non Osà Scegliere per Te

Per verificare i conflitti, ho duplicato il repository. main ha cambiato il titolo principale in "Lascia che la creatività del campus sia vista da più persone", e il branch feature ha cambiato la stessa riga in "Trasforma un'idea in un lavoro veramente utilizzabile". Git si è fermato durante il merge:

I marcatori di conflitto sono divisi in tre parti:

1<<<<<<< HEAD
2Contenuto del branch corrente
3=======
4Contenuto del branch da unire
5>>>>>>> feature/rewrite-heading

Il metodo di gestione è modificare il file, lasciare il testo finale desiderato, eliminare i tre set di marcatori, testarlo, e poi eseguire:

1git add index.html
2git commit

Se non vuoi gestirlo in quel momento, puoi annullare il merge:

1git merge --abort

Un conflitto significa che due persone o due Agenti hanno dato risposte diverse per la stessa posizione, e Git non può scegliere da solo.

9. Inviare il Repository Locale a GitHub

Il progetto ha già una cronologia locale; ora vai su GitHub per creare un repository. Fai clic sul + nell'angolo in alto a destra, seleziona "New repository" e inserisci il nome del repository, ad esempio:

1campus-ai-demo

Per la prima pratica, si consiglia di impostarlo su Privato. Poiché il locale ha già un README, .gitignore e cronologia dei commit, mantieni il nuovo repository GitHub vuoto; non inizializzare README, licenza o .gitignore sul lato web. Altrimenti, il locale e il remoto avranno ciascuno un pezzo di cronologia iniziale, e il primo push richiederà di gestire la relazione tra i due lati prima. La documentazione ufficiale di GitHub "Aggiungere codice ospitato localmente" lo ricorda esplicitamente.

Copia l'indirizzo HTTPS:

1https://github.com/YourUsername/campus-ai-demo.git

Torna al terminale del progetto:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin è un alias per l'indirizzo remoto; può funzionare con altri nomi, ma la comunità chiama abitualmente il repository remoto principale origin. -u stabilirà una relazione di tracciamento tra main locale e origin/main; le operazioni successive di solito eseguono solo git push.

Il diagramma del terminale qui sotto ha utilizzato un repository bare locale per eseguire push e clone, quindi non ha cambiato l'account GitHub esistente. Quando si passa a GitHub, basta sostituire l'URL di origin; la logica per Git di passare i commit e stabilire relazioni di tracciamento è la stessa.

Dopo che il vero push è completato, torna alla pagina web di GitHub e aggiorna per confermare che file, README, branch predefinito e cronologia dei commit siano tutti visibili. Il messaggio di successo nel terminale è un livello di prova, e il controllo web è un altro.

10. Leggere un Repository GitHub per la Prima Volta: Come Leggere Queste Cose sulla Pagina

Qui sotto c'è la pagina reale del repository ufficiale della documentazione di GitHub, screenshot del 15 agosto 2026.

Quando apri un repository, guarda prima queste posizioni:

• Code: File, directory, branch e commit;
• Issues: Bug, requisiti, attività e discussioni;
• Pull requests: Modifiche in attesa di revisione o merge;
• Actions: Test automatizzati, build e deployment;
• Security: Criteri di sicurezza e funzioni relative alle vulnerabilità;
• Insights: Contributi, traffico e attività del repository;
• README: Introduzione al progetto e punto di ingresso per l'utilizzo;
• LICENSE: Come è consentito utilizzarlo, modificarlo e distribuirlo.

Quando leggi un progetto sconosciuto, non fissarti prima sulle Stars. Rispondi prima a cinque domande: Che problema risolve, come si esegue, da cosa dipende, è mantenuto di recente e cosa mi permette di fare la licenza. Le Stars riflettono l'attenzione; non controllano per te la sicurezza, la compatibilità o l'autorizzazione.

11. clone, fetch, pull, push: Non Confondere le Quattro Direzioni

Portare un repository remoto sul tuo computer per la prima volta:

1git clone https://github.com/OWNER/REPO.git

Clone riporta file, cronologia dei commit e configurazioni remote, di solito nominando automaticamente il remoto origin. Scaricare un ZIP dà solo un'istantanea dei file in quel momento, senza cronologia completa, e non stabilirà una relazione remota.

Le tre azioni comunemente usate in seguito sono:

1git fetch origin   # Scarica informazioni remote, non modifica i file di lavoro correnti
2git pull           # fetch e poi integra nel branch corrente
3git push           # Invia i commit locali al remoto

Per vedere prima cosa è successo in remoto, puoi:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Quando confermi che non c'è divergenza in locale e vuoi accettare solo aggiornamenti fast-forward:

1git pull --ff-only

pull eseguirà prima fetch, e poi eseguirà merge o rebase in base alla configurazione. I team dovrebbero concordare il metodo di integrazione prima della prima collaborazione e non fare affidamento su force push per appianare i problemi quando si verifica una divergenza.

12. Dal Repository Personale alla Collaborazione su GitHub

Una Pull Request è una proposta di merge e il luogo in cui avviene la collaborazione. Discussioni, revisioni del codice e controlli automatizzati ruotano tutti attorno allo stesso insieme di modifiche, e viene unita a main solo dopo la conferma.

Supponendo che l'Issue sia "Aggiungi descrizione orario evento", le operazioni locali possono essere fatte così:

1git switch -c feat/event-time
2# Modifica e testa la pagina
3git add index.html
4git commit -m "feat: Aggiungi descrizione orario evento"
5git push -u origin feat/event-time

Dopo il push, GitHub di solito richiede di creare una Pull Request. Una PR è una proposta di merge che mostra descrizioni, commit, differenze file, commenti, revisioni e controlli automatizzati. Non entrerà automaticamente in main solo perché è stata creata.

Una PR che le persone sono disposte a revisionare dovrebbe spiegare almeno tre cose: cosa è stato modificato, perché è stato modificato e come verificarlo. Più le modifiche sono mirate, più è facile per i revisori individuare i problemi.

Nello stesso team, se hai accesso in scrittura al repository, puoi inviare una PR direttamente da un branch. Quando contribuisci a un progetto open-source sconosciuto, la pratica comune è prima farne il Fork nel tuo account, e poi clonare il tuo Fork:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

Di solito ci sono due remote qui:

1origin    Il tuo Fork
2upstream  Il repository dell'autore originale

Sincronizza il progetto originale:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Poi completa le modifiche in un nuovo branch, fai push sul tuo Fork, e poi invia una PR a upstream. Fork, clone e branch risolvono tre cose diverse: Fork è un insieme di spazio del repository su GitHub, clone porta il repository in locale, e branch è una linea di sviluppo all'interno di un repository.

13. README e LICENSE Determinano se Altri Oseranno Usarlo

Un README dovrebbe rispondere almeno a queste domande:

1. Cos'è il progetto;
2. Che problema risolve;
3. Come installarlo o eseguirlo;
4. A che punto è attualmente completato;
5. Dove si trovano i file principali;
6. Chi sono gli autori, i materiali e le fonti di citazione.

Se il codice può essere eseguito ma il README è vago, potresti non essere in grado di riprenderlo in mano tu stesso tre mesi dopo. Un README minimo non deve essere bello; basta scrivere chiaramente il progetto, il metodo di esecuzione e lo stato.

I repository pubblici non equivalgono automaticamente all'ottenimento di una licenza open-source. La spiegazione ufficiale della licenza di GitHub afferma chiaramente: quando non c'è licenza, si applicano comunque le regole predefinite del copyright e l'autore mantiene i diritti di copia, distribuzione e creazione di opere derivate. Pubblico significa che altri possono vederlo e farne il Fork secondo i termini di servizio di GitHub; per prendere il codice nel tuo progetto pubblico o commerciale, devi anche guardare la LICENZA nel repository.

MIT, Apache-2.0, GPL, ecc., hanno obblighi diversi. Quando incontri uso commerciale, ridistribuzione o licenze miste, leggi il file completo e consulta un professionista se necessario; non chiedere semplicemente a un'AI "Posso usarlo per scopi commerciali?"

14. Dopo Aver Sbagliato: Determina in Quale Livello si Trova la Modifica

La medicina del pentimento dovrebbe essere scelta in base allo stato.

Hai messo in staging il file sbagliato ma vuoi mantenere il contenuto del file:

1git restore --staged filename

Il messaggio del commit più recente è stato scritto male e non è stato ancora inviato:

1git commit --amend -m "Nuovo messaggio di commit"

Un commit su un branch condiviso deve essere revocato:

1git revert commit_hash

revert produrrà un nuovo commit inverso, e la vecchia cronologia rimane visibile, il che è adatto per branch che sono già stati inviati e sono usati da più persone.

git restore filename scarterà le modifiche che non sono state committate; git reset --hard farà tornare i commit, l'area di staging e l'area di lavoro a una posizione specificata; git push --force potrebbe sovrascrivere i commit remoti. Questi tre tipi di operazioni richiedono la conferma dell'obiettivo e un backup prima dell'esecuzione; non trattarli come pulsanti di riparazione generici nella fase zero-base.

15. Otto Errori Più Comuni: Controlla in Questo Ordine

1. fatal: not a git repository

1pwd
2ls
3git status

Di solito, la directory è sbagliata, o il progetto corrente non è stato ancora git init.

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

Controlla se il file è stato salvato, se hai modificato un'altra copia e se le modifiche sono già state committate:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin IndirizzoGitHubCorretto

5. src refspec main does not match any

Il repository potrebbe non avere ancora un commit, o il branch corrente non si chiama main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Controlla l'URL remoto, la proprietà del repository, i permessi dell'account e il metodo di autenticazione. Non inviare il Token ad altri per la risoluzione dei problemi.

7. rejected non-fast-forward

Ci sono commit in remoto che non sono in locale. Fai fetch e visualizza le differenze prima; non forzare direttamente il push:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Esegui git status per trovare i file UU, determina manualmente il contenuto finale, testa, poi add e commit; se non lo gestisci per ora, git merge --abort.

Quando uno studente o un collega dice semplicemente "Git è rotto", chiedi loro di fornire questi cinque output:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Poi aggiungi il sistema operativo, il comando completo appena eseguito e il messaggio di errore completo. La maggior parte dei problemi ricadrà rapidamente in uno dei livelli: directory, stato, identità, indirizzo remoto o permessi.

16. Nell'Era dell'IA, Git è Più Come un Sistema di Accettazione

L'IA può digitare comandi per te, ma non può sapere automaticamente quali modifiche soddisfano le intenzioni aziendali. Se un prompt modifica 20 file e non guardi il diff, non esegui il progetto e non controlli le chiavi, Git registrerà fedelmente questo pasticcio.

Un modo più stabile è restringere il compito e mettere l'umano nella posizione di accettazione. Dopo che l'ambito, le differenze, i test e i controlli chiave sono tutti superati, l'umano decide se queste modifiche possono diventare un commit.

Quando si lascia che l'IA operi su Git, dai anche dei confini:

1Controlla prima git status e git diff, e riassumi solo le modifiche correnti.
2Non scartare alcun contenuto non committato, non eseguire reset --hard, clean o force push.
3Fornisci i risultati della verifica dopo aver completato le modifiche, non eseguire commit o push automatici.

Non è più così importante sapere i comandi a memoria. Devi essere in grado di leggere lo stato, sapere cosa ha spostato l'IA, giudicare se la verifica è sufficiente e fermarti quando appaiono operazioni pericolose.

17. Esegui di Nuovo l'Intero Processo

1# 1. Conferma la posizione
2pwd
3ls
4
5# 2. Inizializza
6git init -b main
7git status
8
9# 3. Primo commit
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Inizializza progetto"
13
14# 4. Modifica, controlla, testa, committa di nuovo
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Aggiungi punto di registrazione"
20
21# 5. Esperimento con branch
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Esperimento con tema caldo"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Connetti a GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Controllo finale
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

Quando riesci a spiegare quale livello ogni comando ha modificato e sei in grado di gestire autonomamente una directory sbagliata, un errore di staging e un conflitto di merge, GitHub non è più solo un sito web per memorizzare codice. Sei già in grado di trasformare progetti personali in repository che possono essere revisionati, controllati e su cui si può collaborare.

Il passo successivo non richiede di continuare a collezionare comandi. Trova un vero piccolo progetto e fallo per 7 giorni consecutivi: completa solo una piccola modifica ogni giorno, guarda il diff, testa, committa e poi fai push su GitHub. La cronologia dei commit trasformerà lentamente questo insieme di cose nella tua abitudine di lavoro.

Sono Miles, un esperto di algoritmi IA passato da una grande azienda a FDE. Ho fatto R&D di algoritmi, deployment di ottimizzazione e formazione aziendale. Seguimi @miles_mazy Cresciamo insieme, guadagniamo insieme.