Como você usa o repositório "git --bare init"?

Preciso criar um repositório Git central, mas estou um pouco confuso ...

Eu criei um repositório vazio (no meu servidor git, máquina 2) com:

$ mkdir test_repo
$ git --bare init

Agora, preciso enviar arquivos do meu repositório local (máquina 1) para o repositório vazio (máquina 2). Eu tenho acesso à máquina 2 pelo SSH. O problema é que acho que não entendo o conceito de repositório vazio ...

Qual é a maneira correta de armazenar meu código no repositório vazio? Como posso enviar alterações do meu repositório local para o repositório bare?

É a maneira correta de ter um repositório central para ter um repositório vazio?

Estou um pouco confuso com esse assunto. Por favor, me dê uma pista sobre isso.

Primeiramente, apenas para verificar, você precisa mudar para o diretório que você criou antes de executar git init --bare. Além disso, é convencional dar extensão aos repositórios vazios .git. Então você pode fazer

git init --bare test_repo.git

Para versões Git <1,8, você faria

mkdir test_repo.git
cd test_repo.git
git --bare init

Para responder às suas perguntas posteriores, os repositórios vazios (por definição) não têm uma árvore de trabalho anexada a eles, portanto você não pode adicionar arquivos facilmente a eles como faria em um repositório não vazio normal (por exemplo, com git add <file>e um subseqüente git commit. )

Você quase sempre atualiza um repositório vazio, pressionando-o (usando git push) de outro repositório.

Observe que, neste caso, você precisará primeiro permitir que as pessoas enviem para o seu repositório. Quando dentro test_repo.git, faça

git config receive.denyCurrentBranch ignore

Comunidade editar

git init --bare --shared=group

Como comentado por prasanthv, é isso que você deseja se estiver fazendo isso no trabalho, e não para um projeto de casa particular.

Estou adicionando esta resposta porque, depois de chegar aqui (com a mesma pergunta), nenhuma das respostas realmente descreve todas as etapas necessárias necessárias para ir do nada a um repositório remoto (totalmente) totalmente utilizável.

Nota: este exemplo usa caminhos locais para a localização do repositório vazio, mas outros protocolos git (como SSH indicado pelo OP) devem funcionar bem.

Tentei adicionar algumas notas ao longo do caminho para aqueles menos familiarizados com o git.

1. Inicialize o repositório simples ...

> git init --bare /path/to/bare/repo.git
Initialised empty Git repository in /path/to/bare/repo.git/

Isso cria uma pasta (repo.git) e a preenche com arquivos git representando um repo git. Tal como está, este repositório é inútil - não tem commits e, mais importante, não tem ramos . Embora você possa clonar este repositório, não pode retirá-lo.

Em seguida, precisamos criar uma pasta de trabalho. Existem algumas maneiras de fazer isso, dependendo se você possui arquivos existentes.

2a Crie uma nova pasta de trabalho (sem arquivos existentes) clonando o repositório vazio

git clone /path/to/bare/repo.git /path/to/work
Cloning into '/path/to/work'...
warning: You appear to have cloned an empty repository.
done.

Este comando só funcionará se /path/to/worknão existir ou for uma pasta vazia. Tome nota do aviso - nesta fase, você ainda não tem nada útil. Se você cd /path/to/workexecutar git status, obterá algo como:

On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

mas isso é mentira. Você não está realmente no ramo master(porque git branchnão retorna nada) e, até agora, não há confirmações.

Em seguida, copie / mova / crie alguns arquivos na pasta de trabalho, adicione-os ao git e crie o primeiro commit.

> cd /path/to/work
> echo 123 > afile.txt
> git add .
> git config --local user.name adelphus
> git config --local user.email [email protected]
> git commit -m "added afile"
[master (root-commit) 614ab02] added afile
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

Os git configcomandos são necessários apenas se você ainda não disse ao git quem você é. Observe que se você executar agora git branch, verá a masterramificação listada. Agora execute git status:

On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

nothing to commit, working directory clean

Isso também é enganador - o upstream não "foi", apenas não foi criado ainda e git branch --unset-upstreamnão ajudará. Mas tudo bem, agora que temos nosso primeiro commit, podemos enviar por push e master será criado no repositório simples.

> git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 207 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /path/to/bare/repo.git
 * [new branch]      master -> master

Neste ponto, temos um repositório bare totalmente funcional que pode ser clonado em outro lugar em uma ramificação principal, bem como uma cópia de trabalho local que pode ser puxada e empurrada.

> git pull
Already up-to-date.
> git push origin master
Everything up-to-date

2b. Criar uma pasta de trabalho a partir de arquivos existentes Se você já possui uma pasta com arquivos (para não poder cloná-la), pode inicializar um novo repositório git, adicionar um primeiro commit e vinculá-lo ao repositório bare posteriormente.

> cd /path/to/work_with_stuff
> git init 
Initialised empty Git repository in /path/to/work_with_stuff
> git add .
# add git config stuff if needed
> git commit -m "added stuff"

[master (root-commit) 614ab02] added stuff
 20 files changed, 1431 insertions(+)
 create mode 100644 stuff.txt
...

Nesse ponto, temos nosso primeiro commit e um branch master local, que precisamos transformar em um branch upstream rastreado remotamente.

> git remote add origin /path/to/bare/repo.git
> git push -u origin master
Counting objects: 31, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (31/31), done.
Writing objects: 100% (31/31), 43.23 KiB | 0 bytes/s, done.
Total 31 (delta 11), reused 0 (delta 0)
To /path/to/bare/repo.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Observe a -uflag no git push para definir o (novo) ramo upstream rastreado. Assim como antes, agora temos um repositório vazio totalmente funcional que pode ser clonado em outro lugar em uma ramificação principal, bem como uma cópia de trabalho local que pode ser puxada e empurrada.

Tudo isso pode parecer óbvio para alguns, mas o git me confunde na melhor das hipóteses (as mensagens de erro e status realmente precisam de retrabalho) - espero que isso ajude outros.

Respondendo às suas perguntas uma por uma:

Repositório simples é aquele que não possui árvore de trabalho . Isso significa que todo o seu conteúdo é o que você tem no .gitdiretório.

Você pode apenas commitdescobrir o repositório pushusando o clone local. Não possui uma árvore de trabalho, portanto, não há arquivos modificados, nenhuma alteração.

Ter um repositório central é a única maneira de ter um barerepositório.

Você também pode pedir ao git para criar um diretório para você:

git init --bare test_repo.git

A prática geral é ter o repositório central para o qual você envia como repositório simples.

Se você possui experiência em SVN, pode relacionar um repositório SVN a um repositório bare Git. Ele não possui os arquivos no repositório na forma original. Considerando que seu repositório local terá os arquivos que formam seu "código" além disso.

Você precisa adicionar um controle remoto ao repo bare do seu repo local e enviar seu "código" a ele.

Será algo como:

git remote add central <url> # url will be ssh based for you
git push --all central

Isso deve ser suficiente:

git remote add origin <url-of-bare-repo>
git push --all origin

Consulte para obter mais detalhes " GIT: como atualizo meu repo bare? ".
Notas:

• você pode usar um nome diferente de ' origin' para a referência remota de repositório simples.
• isso não vai empurrar suas tags, você precisa de um separado git push --tags originpara isso.

É bom verificar se o código que você enviou realmente foi confirmado.

Você pode obter um log de alterações em um repositório vazio, definindo explicitamente o caminho usando a opção --relative.

$ cd test_repo
$ git log --relative=/

Isso mostrará as alterações confirmadas como se este fosse um repositório regular do git.

Baseado nas respostas de Mark Longair e Roboprog:

se versão git> = 1.8

git init --bare --shared=group .git
git config receive.denyCurrentBranch ignore

Ou:

se versão git <1.8

mkdir .git
cd .git
git init --bare --shared=group 
git config receive.denyCurrentBranch ignore

O sinalizador --bare cria um repositório que não possui um diretório ativo. O repositório simples é o repositório central e você não pode editar (armazenar) códigos aqui para evitar o erro de mesclagem.

Por exemplo, quando você adiciona um arquivo ao seu repositório local (máquina 1) e o envia ao repositório vazio, não pode ver o arquivo no repositório vazio, pois ele está sempre 'vazio'. No entanto, você realmente envia algo para o repositório e pode vê-lo inexplicavelmente ao clonar outro repositório em seu servidor (máquina 2).

Tanto o repositório local na máquina 1 quanto o repositório 'copy' na máquina 2 não são necessários. relacionamento entre repositórios vazios e não vazios

O blog irá ajudá-lo a entendê-lo. https://www.atlassian.com/git/tutorials/setting-up-a-repository

Você pode executar os seguintes comandos para inicializar seu repositório local

mkdir newProject
cd newProject
touch .gitignore
git init
git add .
git commit -m "Initial Commit"
git remote add origin user@host:~/path_on_server/newProject.git
git push origin master

Você deve trabalhar no seu projeto a partir do repositório local e usar o servidor como repositório central.

Você também pode seguir este artigo, que explica todos os aspectos da criação e manutenção de um repositório Git. Git para iniciantes