Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/antoniolemos316/git-github-dioweb
Curso de git-github da dioweb
https://github.com/antoniolemos316/git-github-dioweb
Last synced: 6 days ago
JSON representation
Curso de git-github da dioweb
- Host: GitHub
- URL: https://github.com/antoniolemos316/git-github-dioweb
- Owner: AntonioLemos316
- Created: 2024-03-30T18:40:16.000Z (8 months ago)
- Default Branch: main
- Last Pushed: 2024-03-31T16:23:36.000Z (8 months ago)
- Last Synced: 2024-04-17T02:22:11.677Z (7 months ago)
- Size: 632 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: readme.md
Awesome Lists containing this project
README
# Git e GitHub na dio
## Sistemas de controle de versão
- Controla as versões de um arquivo ao longo do tempo
- Registra o histórico de atualizações de um arquivo
- Gerencia quais foram as alterações, a data, autor, etc
- Organização, controle e segurança## Tipos de Sistemas de controle de versão
- VCS Centralizado (CVCS) > ex: CVS, Subversion
- VCS Centralizado as versões ficam em um servidor centralizado, caso aconteça algum problema com o servidor ficamos sem poder contribuir até o servidor voltar.
- VCS Distribuído (DVCS) > ex: Git, Mercurial
- VCS Distribuído surgiu em busca de resolver problemas dos CVCS
- Clona o repositório completo, o que inclui o histórico de versões
- Cada clone é como um backup
- Possibilita um fluxo de trabalho flexível
- Possibilidade de trabalhar sem conexão à rede## Git
- DVCS > Sistema de controle de versão distribuído
- Gratuito e Open Source
- Ramificações (branching) e fusões (merging) eficientes
- Leve e rápido
- https://git-scm.com/ about e documentation## Fluxo básico no git
- git clone > clona um repositório git existente para um novo diretório(pasta)local
- git commit > grava alterações no repositório
- git pull > puxa as alterações do repositório remoto para o local(busca e mescla)
- git push > empurra as alterações do repositório local para o remoto## GitHub
- Plataforma de hospedagem de código para controle de versão com Git, e colaboração
- Comunidade ativa
- Utilizado mundialmente
- Git !== GitHub## Gitbash
- git config --global user.name "lemos"
- git config --global user.email "[email protected]"
- git config user.name
- git config user.email
- git config init.defaultBranch // master
- git config --global init.defaultBranch main
- git config init.defaultBranch // main
- git config --global --list // retorna configurações do global user, email, editor e outras
- git config credential.helper cache // temporario > mais de uma pessoa
- git config credential.helper store // permanente > uso pessoal## Primeiros passos git e github criando e clonando repositórios
- Existem duas formas de obter um repositório git na máquina local
- Transformar um diretório local que não está sob controle de versão, num repositório Git com git init- Utilizando cd .git para acessar na pasta o caminho .git que é oculto, esse arquivo é responsavel por gerenciar nosso controle de versão
- Utilizando o ls para ver os arquivos em .git
- Clonando um repositório Git existente com git clone
- Verificando com o ls a pasta que foi clonada
- Podemos clonar o repositório com outro nome
- Criando um repositório local e adicionando o git init e observando com cat config que ele não está associado a nenhum repositório online
- Após utilizar o comando git remote add origin com a url do repositório online que queremos associar no repositório local, conseguimos ver que ele foi associado atraves de cat config
## Salvando alterações locais
- Breve resumo do que foi estudo até agora
- Com o git status observamos como esta o estado atual do repositório
- Com o touch README.md criamos um arquivo na pasta e ao rodar o git status novamente ele mostra o estado atual e a alteração que foi feita e também mostra um sugestão do que pode ser feito
- Com o git add e o nome do arquivo especificamos qual arquivo vamos colocar na staging area para ser incluído no próximo commit
- Com o git commit -m"mensagem" criamos um novo commit no repositório git com uma mensagem associada ao commit
- Com o git log podemos ver os históricos de commit em um repositório git
- Com o git status observamos que não à nenhuma alteração a ser feita
- Ao utilizar o mkdir e criar uma pasta vazia e rodar o git status ele não reconhece a pasta vazia como uma alteração
- Ao utilizar o touch indicando a pasta criada anteriormente, criaremos um arquivo nela, em seguida rodaremos o git status e agora ele consegue ver a pasta
- Com o comando echo o caminho da pasta > .gitignore estamos criando um arquivo .gitignore que dentro dele tera escrito o caminho da pasta
- Com o git status podemos ver que o arquivo .gitignore foi listado com untracked e a pasta praticando-git-e-github foi ignorada
- Ao utilizar echo > .gitignore, criamos um novo arquivo .gitignore vazio, ao roda o git status ele volta a ver a pasta que antes estava ignorada
- Geralmente ao criar uma nova pasta existe uma convenção que é criar dentro dela um arquivo chamado .gitkeep para a pasta não ficar vazia
- Com o git status e utilizando a convenção a pasta sera reconhecida mesmo estando "vazia"
- Com o git add . estamos indicando que vamos adicionar todos os arquivos para a area de staging
- Utilizando o git commit -m"mensagem" fizemos o nosso commit para o repositório do git
- Com o git log observamos nosso histórico de commits
## Desfazendo alterações no repositório local
- Utilizando o rm -rf .git para remover a força o diretório git
- Com o git status vemos que o repositório não é mais um repositório git
- Com o git restore e indicando o nome do arquivo, conseguimos voltar ao último estado do commit caso tenha feito alguma alteração, como apagar o conteúdo do arquivo. Obs: tomar cuidado ao utilizar esse comando
- Com o git commit --amend -m "mens" alteramos a mensagem do nosso ultimo commit
- Com o git reset --soft e o hash do commit, nós voltamos o commit anterior para a area de staging novamente
- Com o git reset --mixed e o hash do commit, voltamos a area de trabalho antes da area de staging
- Com o git reset --hard e o hash do commit, apagamos tudo e voltamos até o ultimo commit. Obs: muito cuidado ao usar esse comando
- Utilizando o git reflog para ter um histórico mais detalhado do repositório local e todas essas alterações deve ser feitas antes de serem enviadas ao repositório remoto
## Enviando e baixando alterações com o repositório remoto
- Pegando as alterações locais e colocando no repositório remoto
- Com o git pull trazemos as alterações do repositório remoto e mesclamos com o repositório local
## Trabalhando com Branches - criando, mesclando, deletando e tratando conflitos
- Uma branch é uma ramificação do projeto
- É um ponteiro móvel para um commit no histórico do repositório
- Quando criamos nova Branch a partir de outra existente, a nova Branch se inicia apontando para o mesmo commit da Branch que estava quando foi criada
- Criar várias Branch é fundamental ao se trabalhar em conjunto para não misturar alterações feitas numa mesma parte do código
- O (HEAD -> main) aponta em qual commit esta a branch- Criação da Branch teste com git checkout -b teste, as duas estão apontando para o mesmo commit
- Ao criar um novo commit dentro da Branch teste, ela apontará para o novo commit
- A Branch nova funciona de forma independente
- Com o git branch -v conseguimos ver a branch e qual é o seu commit
- Estando na Branch main, com o git merge e o nome da Branch que queremos mesclar, pegaremos as alterações feitas na outra Branch e adicionaremos a nossa Branch main
- Com o git branch conseguimos ver as branch's disponíveis e com git branch -d e o nome da branch conseguimos deletar a branch indicada
## Considerações
- Agredicimento a [DioWeb](https://web.dio.me/) e a professora Elidiana.