Usando o git como repositório central

Question

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 eu estiver trabalhando na parte X aqui, e parte Y aqui, e puder mesclar se necessário.

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

Esse tipo de trabalho. Eu tenho um monte de máquinas A-C que fazem um git-pull do 'mestre' M. Eles fazem o git para enviar os dados de volta.

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

git reset --hard HEAD

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

Algo sobre o meu modelo mental está distante. Ajuda?

    

Answer 1

Você quer que seu repositório central esteja vazio. Diga que a máquina em que ele está se chama static :

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

Este repositório nu é um ponto de encontro central: é para empurrar e extrair, não o desenvolvimento.

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

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

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

$ git clone /git/myproject.git

Embora você seja o único que trabalha neste repositório, adquira o hábito de fazer o seu trabalho sobre o que a documentação do git chama de ramos de tópicos . Um benefício imediato disso é que ele mantém um master limpo , ou seja, você pode sempre extrair de sua ramificação principal central para o master 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 se tornar um no flop, você pode facilmente jogar fora esse branch sem quebrar mais nada em seu projeto que já está trabalhando em outros branches. Mulligans infinitos e gratuitos!

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 está no repositório central.

Mas agora digamos que você corrigiu o erro e está pronto para incluí-lo em sua ramificação principal. Primeiro você quer integrá-lo com as mudanças da noite passada:

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

O comando rebase faz seu repositório parecer como se você tivesse corrigido o bug foo no topo do novo recurso da noite passada. (Isso é como svn update , mas mais flexível e poderoso.)

Agora, para entrar 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 trabalhos em diferentes ramos de diferentes repositórios através do repositório git em static com a mesma facilidade.

    

Answer 2

Se você tiver um servidor central com um repositório git central, esse repositório deve ser um repositório bare . Repositórios nus não possuem cópias funcionais dos arquivos neles. Consequentemente, se você está trabalhando nessa máquina central, você não trabalha diretamente com o repositório central, mas com um clone local.

    

Answer 3

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

Eu uso o git para armazenar meus arquivos de configuração de pontos. Eu empurro e puxo do que eu considero um 'repositório central'. É muito conveniente redefinir todos os meus arquivos de ponto em 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 repo.

Agora, se eu já tiver um repo existente localmente, posso enviar isso 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 a origem, para que o push / pull atue sobre o repositório.

$ git push origin master

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

Se eu for para outro host, posso acessar facilmente o clone desse repositório para um novo local.

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

Se eu quiser fazer o desenvolvimento no servidor remoto, clonei primeiro e, em seguida, empurrei / puxei de volta para o repositório nu.

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

Você provavelmente terá que definir seu git config --add branch.master.remote origin , então git pull não reclama que você não está sendo específico o suficiente. A outra alternativa é definir sua ramificação mestre como --track da origem remota. Útil se você tiver vários ramos.

    

Answer 4

Eu estava pesquisando o mesmo problema hoje. Este blog post tem muita discussão sobre a questão, mas a opinião da maioria é fazer o que Manni disse. Olhe para um comentário no post de David French sobre algumas outras possibilidades, incluindo o que fazer se você acabar erroneamente empurrando para um repositório que tenha um trabalho não consolidado no índice ou na árvore de trabalho. "git reset –soft HEAD ^" irá reverter a mudança empurrada sem atrapalhar seu trabalho.