setup git per un singolo sviluppatore?

Question

Spesso ho bisogno di sviluppare cose sulla strada, senza connessione internet/rete. Sono solo un singolo sviluppatore, quindi fino ad ora avevo semplicemente un repository SVN sulla mia macchina e ho fatto un checkout sul mio portatile quando sono andato via. Problema: questo non mi dà il controllo del codice sorgente sulla strada.

Così ho provato a cambiare git, che sembra fare quello che voglio, ma non sono sicuro di aver capito correttamente come dovrebbe essere usato nel mio setup.

In sostanza:

• Creato un repository su \ myserver \ share \ progetto utilizzando git init
• clonati quel repository alla macchina 1 utilizzando git clone
• Cloned quel repository di macchina 2 utilizzando git clone
• Ha lavorato sulla macchina 2, utilizzando git commit per confermare eventuali modifiche al mio repository locale
• F inalmente utilizzato git push per spingere tutte le modifiche al \ myserver \ share \ prohect
• Usato git pull sulla macchina 1 per ottenere nuovi cambiamenti da \ myserver share \ progetto \

che funziona, ma il comando git push me un dà avviso che dice che la spinta del ramo fuori controllo non è supportata in quanto potrebbe confondere l'indice. Ora, sono confuso, perché il messaggio è stato anche scritto in tono serio, il che significa che dovrei onorarlo (e in effetti, Gitk mostra che ora ho due rami: master e remoti/origine/master), ma io non capisco ancora completamente la terminologia.

Quali sarebbero i passaggi corretti nella mia situazione?

• io sempre e solo lavorare sulla macchina 1 OR macchina 2, non sia
• intendo usare ramificazione come un modo per avere un ramo separato per bugfixes/test (come nel solito modo), ma non come un modo per avere più sviluppatori
• Principalmente voglio usarlo come alternativa a rsync my SVN.

Modifica: ci sono due stranezze. Il primo è se cambio semplicemente un file, dice "Modificato ma non aggiornato". che è strano:

# On branch master 
# Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: myproject/Readme.txt 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

Il secondo messaggio è quello che credo sia il colpevole, l'output di git push:

warning: You did not specify any refspecs to push, and the current remote 
warning: has not configured any push refspecs. The default action in this 
warning: case is to push all matching refspecs, that is, all branches 
warning: that exist both locally and remotely will be updated. This may 
warning: not necessarily be what you want to happen. 
warning: 
warning: You can specify what action you want to take in this case, and 
warning: avoid seeing this message again, by configuring 'push.default' to: 
warning: 'nothing' : Do not push anything 
warning: 'matching' : Push all matching branches (default) 
warning: 'tracking' : Push the current branch to whatever it is tracking 
warning: 'current' : Push the current branch 
Counting objects: 7, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (4/4), done. 
Writing objects: 100% (4/4), 333 bytes, done. 
Total 4 (delta 3), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 
warning: updating the current branch 
warning: Updating the currently checked out branch may cause confusion, 
warning: as the index and work tree do not reflect changes that are in HEAD. 
warning: As a result, you may see the changes you just pushed into it 
warning: reverted when you run 'git diff' over there, and you may want 
warning: to run 'git reset --hard' before starting to work to recover. 
warning: 
warning: You can set 'receive.denyCurrentBranch' configuration variable to 
warning: 'refuse' in the remote repository to forbid pushing into its 
warning: current branch. 
warning: To allow pushing into the current branch, you can set it to 'ignore'; 
warning: but this is not recommended unless you arranged to update its work 
warning: tree to match what you pushed in some other way. 
warning: 
warning: To squelch this message, you can set it to 'warn'. 
warning: 
warning: Note that the default will change in a future version of git 
warning: to refuse updating the current branch unless you have the 
warning: configuration variable set to either 'ignore' or 'warn'. 
To file:///\\myserver\share\project 
    129649b..1f4b957 master -> master 

Così mi dice che "spingendo nel ramo corrente" è non raccomandato, ma non ho davvero capito quale sia il modo corretto di farlo.

Answer 1

Altrimenti sembra buono, ma per evitare il messaggio di errore è possibile impostare il repository "upstream" come un repository vuoto, cioè uno che non include una copia ritirata.A tale scopo, con

git --bare init 

Vedi e.g. this example

Answer 2

Il comando git push richiede di specificare un refspec, altrimenti si dovrà modificare .git/config per specificare l'azione predefinita nel caso di mancata refspecs essere specificato. Ad esempio, considerare lo scenario in cui si ha il ramo denominato master.

Per spingere il ramo master, si vuole:

git push refs/heads/master:refs/heads/master 
git push master:master 
git push master 

Tutto quanto sopra sono gli stessi. Il refspec che assomiglia a un percorso è il modo più inequivoco per specificare un refspec. In questo modo, puoi essere certo che ti stai riferendo al ramo master anziché al tag master.

In caso contrario, è possibile modificare .git/config e aggiungere:.

[push] 
    default = matching 

Questo permetterebbe ad appena git push, e Git spingerà al ramo a distanza della sezione locale cui ci si trova, ad esempio, se si sono attualmente nel ramo master, git push invierà il ramo master locale al ramo master remoto.

Come è stato affermato da janneb, sarà necessario utilizzare un repository nudo inorder per inviarlo senza alcun avviso. Il problema con il push su un repository normale (non semplice) è che, il proprietario principale (del particolare repository "normale") non vorrà aggiungere modifiche al proprio repository. A quel punto, se qualcuno preme su questo repository e cancella un ramo (o qualsiasi altra modifica), il proprietario non si aspettava una tale modifica. Quindi, l'avvertimento.

Answer 3

Lei sembra avere buone risposte alla tua domanda principale, quindi mi affrontare questo:

... se ho semplicemente cambiare un file, si dice "Cambiato ma non aggiornato". che è strano ...

Git, a differenza ogni altro sistema di controllo di versione tra quelle, richiede un'azione esplicita dell'utente per includere i file modificati nel set di cose da impegnare successivo. Devi dire

$ git add <your modified files> 

dopo loro e modifica prima di faregit commit. Ho l'impressione che questo sia per rendere più facile il commit selettivo di alcune delle tue modifiche.

Se si esegue il "git add" e quindi si modificano i file, è necessario eseguire nuovamente "git add" oppure le modifiche verranno applicate solo fino al primo "git add".

C'è un collegamento, git commit -a, che esegue più o meno le operazioni di "commit" di altri VCS. Dico "più o meno" perché non sono sicuro che sia una corrispondenza esatta in tutti i casi. L'unica divergenza che conosco è che alcune versioni precedenti di git aggiungerebbero tutti i file modificati e a tutti i nuovi file e quindi eseguiranno il commit; questo è stato corretto nella versione attuale, ma non mi fido ancora della cosa.