WikiDoS

Essa página está em modo somente de leitura. Você pode visualizar a fonte, mas não alterá-la. Informe-se com o administrador do Wiki, caso você ache que isso está incorreto.
====== GIT ======


===== Comandos Git =====

^ Comandos      ^ Descrição       ^
| git status |      
| git add <filename>  | adiciona o arquivo <filename> como ''staged''|
| git add .  | adiciona todos os arquivos modificados como ''staged'' |
| git commit |registrar as mudanças no repositório - abre um editor de texto padrão|
| git commit --amend| junta com o commit anterior, utilize com cuidado|
| git commit -m "mensagem"   |registrar as mudanças no repositório|
| git push origin main  |subir mudanças no repositório    |
| git pull origin main  |baixar mudanças para o repositório local   |
| git log  | Logs list   |
| git log --oneline  | Logs list resumido    |
| git remote -v   |      |
| git remote remove origin  | Remover um repositório remoto |
| git remote rename origin novo-origin    | Alterar o apelido de um repositório remoto     |
| git clone <endereço> | clona o repositório e já adiciona o repositório remoto     |
| git remote  |      |
| git branch | Lista as branches do repositório      |

===== Git Ignore =====

Para ser ignorado pelo git, 
coloque na pasta raiz o arquivo ''.gitignore'', 
//pode-se verificar se os arquivos estão sendo ignorado// antes mesmo de fazer o commit utilizando ''git status'':

<file .gitignore .gitignore>

temp
arquivo.txt
*.temp

</file>

[[https://www.toptal.com/developers/gitignore/|Site para ajudar a criar um .gitignore]]
===== Conflitos & Merge =====

Quando o mesmo arquivo é modificado na mesma linha, tendo uma versão no servidor (não sincronizada) e outra sendo enviada ocorre o **merge**. Dando essa retorno e a escolha da modificação deve ser realizada. Fazendo a escolha das linhas manualmente e posteriormente adicionando os arquivos e fazer o commit novamente.

===== Colaboração Softwares Open Source =====


Em um projeto que segue o modelo Open Source, as demandas, como novos recursos e correção de bugs, são descritas e listadas no repositório do GitHub via **issues**. Assim, caso você queira colaborar, é possível escolher uma **issue**.

Você precisará realizar um **fork** do projeto, que é uma cópia do repositório em sua conta. Assim, você poderá escrever o código que soluciona a **issue** escolhida.

Por fim, para enviar sua solução de volta ao repositório fonte, você precisará abrir um **pull request**, que é uma solicitação de pull das suas alterações. Esse **pull request** passará por um processo de avaliação dos responsáveis pelo projeto, podendo ser aceito ou não.

Caso seja aceito, seu código agora fará parte do código fonte desse projeto.

===== Commit =====

O controle de mudanças do Git é feito através dos commits. Cada commit armazena o estado completo do projeto em um determinado momento por meio de um snapshot. Ou seja, cada commit é um registro completo do repositório no momento em que esse commit foi criado.

Como cada commit é uma representação completa e consistente do estado do projeto em um determinado ponto no tempo, isso facilita a rastreabilidade e o entendimento de como se deu a evolução do código ao longo do tempo.

Todo commit conta com um id único e traz uma referência aos commits anteriores. Assim, através dessa cadeia de commits, o Git registra um histórico completo de todos os commits realizados no repositório.

==== Boas práticas ====


As mensagens dos commits devem ser simples e objetivas. A seguir, listamos algumas orientações para isso:

  * **Mantenha a mensagem curta e concisa:** A primeira linha da mensagem deve conter, no máximo, 72 caracteres. Caso seja necessário uma descrição adicional, você deve pular uma linha e adicionar os detalhes, como o contexto, da mudança realizada.
  * **Uso de verbo no infinitivo:** É comum que a mensagem do commit inicie com um verbo no infinitivo que descreva a alteração feita, como “adicionar”, “corrigir” ou “atualizar”. Em sequência, são adicionados detalhes concisos da mudança. Por exemplo: “Atualizar texto do título da página”.
  * **Evite detalhes técnicos:** Não inclua detalhes técnicos complexos na mensagem de commit. Esses detalhes podem ser adicionados nos comentários de código ou na documentação.
  * Um commit deve ser realizado sempre que você finalizar uma tarefa específica ou resolver algum bug. Isso mantém o histórico de commits claro e rastreável, de modo que seja possível entender o que foi feito em cada commit.
  * É importante realizar commits frequentemente. Porém, evite realizar commits muito pequenos ou muito grandes, pois isso pode tornar difícil o seu entendimento.
  * Lembre-se de nunca realizar um commit de um código que você sabe que contém bugs. O ideal é que o commit contenha somente código funcional.

==== Adicionando colaboradores no commit ====

O Git oferece a possibilidade de adicionar mais de um autor a um commit. Para isso, após escrever a mensagem do commit, pulamos duas linhas e usamos a palavra-chave Co-authored-by:, seguido do nome e e-mail associado ao GitHub (entre < >) de cada pessoa colaboradora.

Cada coautor deve estar em uma linha diferente, como é mostrado no exemplo a seguir:

<code>
$ git commit -m "Adicionar nova funcionalidade.
>
>
Co-authored-by: NOME <nome@email.com>
Co-authored-by: OUTRO-NOME <outro@email.com>"
</code>

===== Alterando Commits=====

É importante destacar que os comandos do Git que permitem modificar o histórico de commits devem ser utilizados com prudência e apenas quando o commit em questão ainda não foi enviado ao repositório remoto, ou seja, quando ele existe apenas no seu repositório local.

Modificar um commit que já se tornou público, ou seja, aquele que já foi enviado ao GitHub ou a qualquer outro repositório remoto, pode acarretar problemas consideráveis na colaboração com as outras pessoas e na integridade do histórico de um projeto.

Em situações de colaboração em equipe, é essencial manter a integridade do histórico de commits, pois qualquer modificação em um commit que outras pessoas estejam trabalhando pode resultar em conflitos e dificuldades na colaboração.

É recomendável evitar a modificação excessiva do histórico de commits, uma vez que isso pode tornar o histórico confuso. O histórico deve ser uma representação precisa do progresso do projeto ao longo do tempo.

==== Desfazendo Commit / commit revert ====

  - Pegue o ID do commit que queira reverter:
    *<code>git log</code>
  - Retorne utilizando:
    *<code>git revert <hash> </code>
  - Isso fará um novo commit retornando as configurações anteriores, para enviar as configurações:
    *<code>git push origin main</code>

==== Remover Commit ====

Recomendado apenas caso tenha feito localmente o commit.

  - Pegue o ID do commit **ANTERIOR** ao que queira reverter:
    *<code>git log</code>
  - Retorne utilizando:
    *<code>git reset --hard <hash> </code>

==== Edita o último Commit ====

    *<code>git commit --amend -m "mensagem" </code>


===== README.md =====

O arquivo utiliza a linguagem de marcação de texto **Markdown**. Segue uma estrutura básica:

<file .md README.md>
# Título
<h1>Título</h1>
<h1 align="center"> Título Centralizado </h1>

<h2Subtítulo></h2>
## Subtítulo

##Imagens
![descrição da imagem](url da imagem gerado pelo serviço de hospedagem ou GitHub)

##Badges-emblema-insígnia
![Badge em Desenvolvimento](http://img.shields.io/static/v1?label=STATUS&message=EM%20DESENVOLVIMENTO&color=GREEN&style=for-the-badge)

<p align="center">
<img loading="lazy" src="http://img.shields.io/static/v1?label=STATUS&message=EM%20DESENVOLVIMENTO&color=GREEN&style=for-the-badge"/>
</p>

##stars do projeto
![GitHub Org's stars](https://img.shields.io/github/stars/camilafernanda?style=social)

# Índice 

* [Título e Imagem de capa](#Título-e-Imagem-de-capa)
* [Badges](#badges)
* [Índice](#índice)
* [Descrição do Projeto](#descrição-do-projeto)
* [Status do Projeto](#status-do-Projeto)
* [Funcionalidades e Demonstração da Aplicação](#funcionalidades-e-demonstração-da-aplicação)
* [Acesso ao Projeto](#acesso-ao-projeto)
* [Tecnologias utilizadas](#tecnologias-utilizadas)
* [Pessoas Contribuidoras](#pessoas-contribuidoras)
* [Pessoas Desenvolvedoras do Projeto](#pessoas-desenvolvedoras)
* [Licença](#licença)
* [Conclusão](#conclusão)

## Status do Projeto
> :construction: Projeto em construção :construction


<h4 align="center"> 
    :construction:  Projeto em construção  :construction:
</h4>


## Funcionalidades e demonstação da aplicação

# :hammer: Funcionalidades do projeto

- `Funcionalidade 1`: descrição da funcionalidade 1
- `Funcionalidade 2`: descrição da funcionalidade 2
- `Funcionalidade 2a`: descrição da funcionalidade 2a relacionada à funcionalidade 2
- `Funcionalidade 3`: descrição da funcionalidade 3

# 📁 Acesso ao projeto

**Indique como é possível baixar ou acessar o código fonte do projeto, seja projeto inicial ou final**

# 🛠️ Abrir e rodar o projeto

**Apresente as instruções necessárias para abrir e executar o projeto**

#tecnologias utilizadas
-item
-item2
-item3

#Contribuidoras

# Autores

| [<img loading="lazy" src="https://avatars.githubusercontent.com/u/37356058?v=4" width=115><br><sub>Camila Fernanda Alves</sub>](https://github.com/camilafernanda) |  [<img loading="lazy" src="https://avatars.githubusercontent.com/u/30351153?v=4" width=115><br><sub>Guilherme Lima</sub>](https://github.com/guilhermeonrails) |  [<img loading="lazy" src="https://avatars.githubusercontent.com/u/8989346?v=4" width=115><br><sub>Alex Felipe</sub>](https://github.com/alexfelipe) |
| :---: | :---: | :---: |

# Licença


<div>
<img src="">
<img src="">
</div>
#Time
|
|

</file>

[[https://shields.io/| Crie insignias]]