Tomando o Linux como exemplo, a plataforma Windows é a mesma do Linux.
Na frente (2.2.1 clique no botão "Novo projeto" para criar um projeto) As instruções da linha de comando aparecem ao criar um novo projeto e quase todas as operações abaixo giram em torno desses comandos.
Instruções de linha de comando
Configuração global do Git
O Git precisa ser configurado no primeiro uso
git config --global user.name "yhh"
git config --global user.email "[email protected]"Criar um novo repositório
Clone um projeto vazio do repositório remoto e crie novos arquivos.
git clone [email protected]:example_firmware/test.git
cd test
touch README.md
git add README.md //1.将代码从工作区中添加到版本库暂存区中去
git commit -m "add README" //2.把暂存区的所有修改提交到master分支上去
git push -u origin master //3.把分master支上代码push到远程仓库中去
Pasta existente
Geralmente usamos esse comando para enviar o código do projeto existente para a biblioteca remota.
cd existing_folder
git init //创建版本库，后面会有详细介绍（只有第一次操作即可，后面不用操作）
关联仓库（两种push代码方式）
git remote add origin http://example.wicp.vip/example_firmware/test.git /*走http协议（只有第一次操作即可，后面不用操作）*/
git remote add origin [email protected]:example_firmware/plug-in_framework.git /*走SSH协议 （只有第一次操作即可，后面不用操作）*/
git add . //1.将代码从工作区中添加到版本库暂存区中去
git commit -m "Initial commit" //2.把暂存区的所有修改提交到master分支上去
git push -u origin master //3.把分master支上代码push到远程仓库中去O repositório Git existente
não fez pesquisa (omitido)
1. Crie uma biblioteca de versões
Execute no diretório de trabalho do projeto correspondente da plataforma linux: após o git init, um arquivo .git será gerado no diretório de trabalho correspondente. Isso é usado para rastrear a biblioteca de versão de gerenciamento de biblioteca. Não exclua isso no futuro, caso contrário, todos os registros git anteriores serão destruídos.
2. Armazém associado
Associe o warehouse local ao warehouse remoto antes de adicionar conteúdo ao warehouse remoto.
modo SSH
git remote add origin [email protected]:example_firmware/plug-in_framework.git método HTTP
git remote add origin http://example.wicp.vip/example_firmware/test.git3. Gerenciamento de código
Para gerenciamento de código, vários comandos comumente usados são, na verdade, três truques.
3.1 Ver status do código
Executando uma ordem:
git status
3.2 Adicionar código ao repositório
Executando uma ordem:
git add .3.3 Adicionar código à ramificação
Executando uma ordem:
git commit -m “初次提交”
3.4 Envie o código da filial para a biblioteca remota
Executando uma ordem:
git push -u origin master(第一次执行命令需要加上-u，后面就不需要)
4. Reversão de versão
Em nosso trabalho, muitas vezes queremos saber quantas versões submetemos no repositório, execute o comando:
git log 
ou comando:
git log --pretty=onelin 
Dentre eles, o commit 4b10e619d0b82c574a34b2266ca40ad13b7d5622 é o id de cada versão calculado pelo SHA1.
ou comando:
git reflog4.1 Reversão do código para a versão anterior
Executando uma ordem:
git reset --hard HEAD^
Entre eles, HEAD é o ponteiro da versão atual, ^ significa a versão anterior e ^^ significa a versão anterior.
4.2 Versão especificada de reversão de código
Comando comando:
git reset --hard 57d3f9aa669dc646697064a97810b842a50fe1bc
4.3 Reversão do código para a versão mais recente
O primeiro passo é executar o comando:
git reflog //找到所有版本的commit id 
O segundo passo é executar o comando:
git reset --hard 4b10e61
5. Múltiplas filiais
Para o desenvolvimento normal, geralmente reservamos o branch master para a versão de lançamento e o branch dev para desenvolvimento de teste.
5.1 Criar uma nova filial
Execute um comando:
git checkout -b devEste comando pode ser dividido em duas etapas:
git branch dev和git checkout dev
Observação: ao alternar o branch dev, você precisa confirmar o código no branch master para a biblioteca de versões, caso contrário, a troca não será bem-sucedida ou o código original não será salvo.
5.2 Exibir ramificação
Executando uma ordem:
git branch
Indica que o desenvolvimento agora pode ser realizado na ramificação dev, conforme mostrado em fonte verde na figura.
5.3 Fusão de filiais
Modifique o código no branch dev e envie-o para o repositório e, em seguida, insira o branch master para executar o comando:
git merge dev5.4 Excluir ramificação
Executando uma ordem:
git branch -d dev
5.5 O conflito de mesclar branches
O chamado conflito significa que vários branches não estão sincronizados. Geralmente, antes de modificar o código do branch master, devemos puxar o código primeiro, caso contrário, ocorrerão os seguintes conflitos. Nesse caso, iremos É necessário editar manualmente o arquivo que falhou ao mesclar com o git para o conteúdo que desejamos e, em seguida, enviá-lo.
Etapa 1: crie e modifique uma ramificação e confirme. do seguinte modo:
Passo 2: Alterne para o branch master, modifique o branch master e então mescle o branch dev1.
Você pode ver que há conflitos de mesclagem e verificar readme.txt ao mesmo tempo
Esta situação é um conflito e o conflito deve ser resolvido manualmente antes do envio. Exclua a parte desnecessária de readme.txt e confirme-o.
Executando uma ordem:
git log --graph --pretty=oneline --abbrev-commitVocê pode visualizar a situação de mesclagem da ramificação, conforme mostrado na figura.
5.6 Colaboração entre várias pessoas
Quando várias pessoas colaboram, todos enviarão suas próprias modificações para as ramificações master e dev. Suponha que você seja A e haja uma pessoa B que clona em outro computador (observe que a chave SSH deve ser adicionada ao GitLab) ou outro diretório do mesmo computador.
Executando uma ordem:
git clone [email protected]:xxx_firmware/test.git
Por padrão, é o branch master, conforme segue: git branch
Neste ponto, B desenvolverá e enviará o código para o branch dev
Então A também fez uma modificação e empurrou o código para a ramificação dev ao mesmo tempo, da seguinte maneira
O exemplo acima mostra que o push falhou, porque há um conflito entre o envio mais recente de B e o envio de A. A solução é obter primeiro o código da biblioteca remota, conforme mostrado na figura abaixo.
Observação: quando a extração do código falhar, você precisa especificar a associação entre o branch dev local e o branch origin/dev da biblioteca remota. Ao mesmo tempo, verifique a modificação da ramificação readme.txt local, você pode encontrar
Este tempo é o mesmo que o conflito da ramificação de mesclagem 5.6. Envie depois de resolver e, finalmente, empurre.
6. Configuração do rótulo e número da versão
O Gitlab não envia um código de versão com um ID de confirmação. Podemos rotulá-los de acordo com esses IDs de confirmação. Esse rótulo pode ser um número de versão.
6.1 Guia Padrão
O rótulo padrão é impresso no commit mais recente da seguinte forma:
6.2 Especifique uma tag no id do commit
Primeiro passo:
git log --pretty=oneline --abbrev-commit
Encontre o ID de confirmação da versão de confirmação em todas as ramificações principais
Passo dois:
git tag v0.9 8c1b181Especifique a confirmação para o rótulo
6.3 Ver informações específicas do rótulo específico
Executando uma ordem:
git show v0.9
6.4 Etiquetas push
Empurre uma etiqueta:
git push origin v1.0Empurre todas as tags:
git push origin –tags
Observe o lado da Web neste momento:
Este é o rótulo.
6.5 Excluir tags
Se o rótulo existir apenas localmente, execute o comando diretamente:
git tag -d v1.0 Se o tag foi enviado para o remoto, o primeiro passo é excluir o tag remoto
, primeiro exclua o tag local:
git tag -d v1.0A segunda etapa é excluir o rótulo remoto:
git push origin :refs/tags/v1.0