Usando o git como um repositório central

Eu configurei o git para meu próprio uso - para que eu possa acessar um projeto de 'qualquer lugar' e manter a segurança da versão, se estiver trabalhando na parte X aqui e na parte Y aqui, e pode mesclar, se necessário.

No entanto, apenas uma das minhas máquinas de desenvolvimento tem um IP estático. Meu cérebro está travado no modo CVS, então tentei configurar o git para que essa máquina fosse o servidor 'central', do qual todos os outros puxam.

Este tipo de obras. Eu tenho um monte de máquinas AC que fazem um git-pull do 'mestre' M. Eles fazem git push para enviar os dados de volta.

O problema vem se eu fizer o desenvolvimento no mestre. Primeiro, não consigo descobrir como obter o repositório central para fornecer a versão mais recente sem precisar

git reset --hard HEAD

o que parece um pouco excessivo. E se eu fizer o desenvolvimento na máquina central antes de redefinir, não sei como mesclá-la com as alterações que já foram enviadas.

Algo no meu modelo mental está muito distante. Socorro?

Você deseja que seu repositório central fique vazio. Digamos que a máquina em que ele vive tenha o nome static:

$ ssh static git init --bare /git/myproject.git

Esse repositório simples é um ponto central de encontro: é para empurrar e puxar, não para o desenvolvimento.

Faça seu desenvolvimento em clones do repositório central:

$ cd ~/src
$ git clone static:/git/myproject.git

Mesmo se você estiver participando static, trabalhe em um clone:

$ git clone /git/myproject.git

Embora você seja o único a trabalhar neste repositório, adquira o hábito de fazer o que a documentação do git chama de ramificações de tópicos . Um benefício imediato disso é que ele mantém um mestre limpo , ou seja, você sempre pode extrair da ramificação do mestre central para o mestre do seu repositório local atual sem mesclar.

Por exemplo:

$ git checkout -b fix-bug-in-foo
$ hack
$ git add file.c file.h
$ git commit -m "Fix ..."

Isso pode não parecer grande coisa, mas dá a você a liberdade de deixar o projeto como representado naquele ramo em um estado parcialmente cozido, ou se a sua ideia legal acabar sendo um fracasso, você pode facilmente jogar fora esse ramo sem quebrando qualquer outra coisa em seu projeto que já esteja trabalhando em outras ramificações. Mulligans grátis infinitos!

Talvez você vá para casa naquela noite e tenha adicionado um novo recurso. Na manhã seguinte, você

$ git checkout master
$ git pull

para atualizar seu mestre local para refletir o que há no repositório central.

Mas agora diga que você corrigiu o erro foo e está pronto para incluí-lo no seu ramo principal. Primeiro você deseja integrá-lo às mudanças da noite passada:

$ git checkout fix-bug-in-foo
$ git rebase master

O rebasecomando faz com que seu repositório pareça que você corrigiu o bug foo sobre o novo recurso da noite passada. (É mais ou menos assim svn update, mas mais flexível e poderoso.)

Agora, coloque-o no seu mestre central:

$ git checkout master
$ git merge fix-bug-in-foo
$ git push origin master

Temos tratado o mestre como especial, mas isso é apenas convencional. Você pode compartilhar o trabalho em diferentes ramos de diferentes repositórios através do repositório git com statica mesma facilidade.

Se você possui um servidor central com um repositório git central, esse repositório deve ser um barerepositório. Repositórios vazios não têm cópias de trabalho dos arquivos neles. Consequentemente, se você estiver trabalhando nessa máquina central, não trabalha diretamente com o repositório central, mas com um clone local.

Essa resposta é semelhante à resposta do gbacon , mas adota uma abordagem de que você já possui uma configuração de repositório local e deseja criar um mestre remoto que é tratado como um repositório central. É apenas adicionar detalhes de uma abordagem diferente.

Eu uso o git para armazenar meus arquivos de configuração de pontos. Eu empurro e puxo o que considero um "repositório central". É bastante conveniente redefinir todos os meus arquivos de ponto através de vários computadores.

$ ssh example.com
$ mkdir dotconf.git && cd dotconf.git
$ git init --bare
$ exit

Isso criou um repositório vazio vazio no site do repositório.

Agora, se eu já tenho um repositório existente localmente, posso enviá-lo para o site remoto.

$ cd ~/src/dotconf

chdir no diretório local.

$ git remote add origin ssh://example.com/~/dotconf.git

Adicione o repositório remoto como origem, para que o push / pull atue nesse repositório.

$ git push origin master

Empurre o meu mestre para a origem (como rotulado anteriormente via git remote). Agora esse repo remoto é tratado como meu 'repo central'. Todo o meu git push / pull irá interagir com a origem.

Se eu for para outro host, eu posso facilmente puxar via clone que repo para um novo local.

$ git clone ssh://example.com/~/dotconf.git

Se eu quiser fazer o desenvolvimento no servidor remoto, clonarei primeiro e empurre / puxe de volta para o repositório simples.

$ cd ~/src
$ git clone ~/dotconf.git
$ cd ~/src/dotconf
  * do coding *
$ git push
  * check in from another location *
$ git pull

Você provavelmente precisará definir o seu git config --add branch.master.remote originpara git pullnão reclamar que não está sendo específico o suficiente. A outra alternativa é definir sua ramificação principal para --tracka origem remota. Útil se você tiver vários ramos.

Eu estava apenas pesquisando esse mesmo problema hoje. Esta postagem do blog tem muita discussão sobre o assunto, mas a opinião da maioria é fazer o que Manni disse. Observe um comentário na postagem de David French sobre outras possibilidades, incluindo o que fazer se você acabar enviando por engano para um repositório que tenha trabalho não confirmado no índice ou na árvore de trabalho. "git reset –soft HEAD ^" recuperará a alteração pressionada sem atrapalhar seu trabalho.