Alguns _workflows_ de contribuição como pré-visualização de páginas para o Guia ou Desafios de Código, _debugging_ e correção de _bugs_ no código requerem que você rode freeCodeCamp localmente.
## Dê _Fork_ no repositório do GitHub
['Dar _fork_'](https://help.github.com/articles/about-forks/) é obter sua própria cópia do repositório principal do _freeCodeCamp_ (a.k.a _repo_) no GitHub.
Isso é essencial, pois assim você pode trabalhar com sua cópia do freeCodeCamp no GitHub, ou baixá-la para trabalhar localmente. Depois, você poderá requisitar que suas mudanças sejam enviadas para o repositório principal via _pull request_.
> **Dica:**
> O repositório principal em `https://github.com/freeCodeCamp/freeCodeCamp` é comumente chamado de repositório `upstream`.
> Seu fork em `https://github.com/SEU_USUARIO/freeCodeCamp` é comumente chamado de repositório `origin`.
**Siga estes passos para dar _fork_ no repositório `https://github.com/freeCodeCamp/freeCodeCamp`:**
1. Vá para o repositório do freeCodeCamp no GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
2. Clique no botão "Fork" no canto superior direito da tela ([Mais detalhes aqui](https://help.github.com/articles/fork-a-repo/))
3. Depois do _fork_ do repositório, você será levado à sua cópia do freeCodeCamp em `https://github.com/SEU_USUARIO/freeCodeCamp`
Uma vez que os pré-requisitos estão instaladas, você precisa preparar seu ambiente de desenvolvimento. Isso é comum para muitos _workflows_ de desenvolvimento, e você precisará fazer isso uma única vez.
**Siga estes passos para preparar seu ambiente de desenvolvimento:**
1. Instale o [Git](https://git-scm.com/) ou seu _client_ de Git favorito, se você ainda não o possui. Atualize para a versão mais recente, já que a versão que veio em seu OS pode estar desatualizada.
2. (Opcional, mas recomendado) [Configure sua chave SSH](https://help.github.com/articles/generating-an-ssh-key/) para o GitHub.
3. Instale um editor de código da sua escolha.
Nós recomendamos fortemente usar o [VS Code](https://code.visualstudio.com/) ou o [Atom](https://atom.io/). Este são ótimos editores: grátis e _open source_.
4. Configure o _linting_ em seu editor de código.
Você deve ter o [ESLint rodando no seu editor](http://eslint.org/docs/user-guide/integrations.html), e isso irá destacar qualquer elemento que não segue o [Guia de Estilo para JavaScript do freeCodeCamp](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121).
> Por favor não ignore nenhum erro de _linting_. Eles existem para te **ajudar** e garantir um código simples e limpo.
## Dê _clone_ na sua cópia do freeCodeCamp
['Clonar'](https://help.github.com/articles/cloning-a-repository/) é **baixar** uma cópia de um repositório que pertence à você ou à outra pessoa, de um local remoto ou `remote`_location_. No seu caso, este local remoto é o seu `fork` repositório do freeCodeCamp, que deve estar disponível em `https://github.com/SEU_USUARIO/freeCodeCamp`.
Rode os seguintes comandos em sua máquina:
1. Abra o Terminal / Prompt de Comando / Bash Shell em seu diretório de projetos
_Por exemplo: `/seudiretoriodeprojetos/`_
2._Clone_ seu _fork_ do freeCodeCamp, substituindo `SEU_USUARIO` pelo seu nome de usuário do GitHub
Isso irá baixar o repositório do freeCodeCamp integralmente em seu diretório de projetos.
## Configure um `upstream` para o repositório principal
Agora que você já baixou uma cópia do seu _fork_, você precisará configurar um `upstream`.
Como foi mencionado anteriormente, o repositório principal `https://github.com/freeCodeCamp/freeCodeCamp` é comumente chamado de repositório `upstream`. Seu _fork_ em `https://github.com/SEU_USUARIO/freeCodeCamp` é comument chamado de repositório `origin`.
Você precisa apontar sua cópia local para o `upstream` alem de apontar para `origin`. Isso acontece para que você possa sincronizar com mudanças do repositório principal. Dessa forma, você não precisa pelo processo de _fork_ e _clone_ várias vezes.
1. Mude de diretório para o diretório do freeCodeCamp:
```shell
cd freeCodeCamp
```
2. Adicione o repositório principal do freeCodeCamp como um local remoto ou _remote_:
## Rodando o freeCodeCamp localmente em sua máquina
Agora que você tem uma cópia local do freeCodeCamp, você pode seguir essas instruções para fazê-la rodar localmente. Isso irá te ajudar a:
- Pré-visualizar páginas da forma que aparecerão na plataforma.
- Trabalhar com problemas relacionados à UI e melhorias.
- _Debuggar_ e corrigir problemas nos _application servers_ e _client apps_.
Você pode pular a parte de rodar o freeCodeCamp localmente se você está apenas editando arquivo, fazendo `rebase` ou resolvendo conflitos de `merge`. Você pode sempre retornar à essa parte das instruções.
[Pular Rodando o freeCodeCamp localmente em sua máquina](#making-changes-to-your-clone-of-freecodecamp-locally)
| [MongoDB Community Server](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [Notas de atualização](https://docs.mongodb.com/manual/release-notes/), Obs: Estamos atualmente na versão `3.6`, uma [nova atualização está planejada](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275). |
| npm (vem junto com o Node) | `6.x` | Não possui uma versão LTS, usamos a versão que vêm com o Node LTS |
**Importante:**
Recomendamos fortemente atualizar para as versões estáveis mais recentes, ou seja, as versões _LTS_ mencionadas acima. (_LTS_ significa _Long Term Service_ ou _Suporte à longo prazo_)
Se o Node.js or MongoDB já estiverem instaladas em sua máquina, rode os seguintes comando para verificar as versões:
```shell
node -v
mongo --version
npm -v
```
> Se você possui uma versão diferente, por favor instale as versões recomendadas. Só poderemos ajudar com problemas de instalações das versões recomendadas.
**Estou tendo problemas instalando os pré-requisitos recomendados. O que eu devo fazer?**
Normalmente, desenvolvemos utilizando sistemas operacionais mais populares e atualizados como o macOS 10.12 ou posterior, Ubuntu 16.04 ou posterior e Windows 10. É recomendado que você verifique seu problema específico em fontes como: Google, Stack Overflow ou Stack Exchange. Há chances de que haja alguém que já enfrentou o mesmo problema que o seu e que exista uma resposta pronta para o que você precisa.
Se você usa um sistema operacional diferente e/ou ainda está com problemas, vá para a [_contributors community_ no nosso fórum público](https://www.freeCodeCamp.org/c/contributors) ou o [Chat de Contribuidores](https://gitter.im/freeCodeCamp/Contributors). Podemos te ajudar a solucionar seu problema.
Não podemos prover suporte no GitHub, pois problemas de instalação de _software_ estão além do escopo deste projeto.
### Instalando dependências
Comece instalando as dependência necessárias para que a aplicação rode.
```shell
# Instala dependências NPM
npm install
```
Depois você precisará adicionar as variáveis de ambiente privadas (_API Keys_)
```shell
# Crie uma cópia de "sample.env" e chame-a de ".env".
# Preencha-a com as API Keys e outras senhas necessárias:
# macOS / Linux
cp sample.env .env
# Windows
copy sample.env .env
```
As chaves não precisam ser alteradas para rodar a aplicação localmente. Você pode deixar os valores padrão de `sample.env` como estão.
`MONGOHQ_URL` é a mais importante. A não ser que você tenha o MongoDB rodando em uma configuração diferente da padrão, a URL em `sample.env` deve funcionar normalmente.
Você pode deixar as outras chaves como estão. Tenha em mente que se você quiser usar mais serviços, você precisará obter suas próprias chaves e editá-las no arquivo `.env`.
Agora vamos "linkar" vários serviços como o _api-server_, o _client UI application_, etc. Você [aprender mais sobre esses serviços neste guia](#).
Esses serviços são semi-independentes. Significa que, em produção, o _deploy_ é feito em locais diferentes, mas estão todos disponíveis para você quando o projeto está sendo rodado localmente.
> Nota do Tradutor: neste trecho, é utilizado o termo _bootstrap_. Este termo foi substituído por _linkar_, já que não achei uma forma melhor para o termo.
```shell
# Bootstrap ou linkar todos os projetos deste repositório
npm run bootstrap
```
### Inicie o MongoDB
Você precisará iniciar o MongoDB, antes que a aplicação possa rodar:
Inicie o servidor do MongoDB em um terminal separado:
- Em macOS & Ubuntu:
```shell
mongod
```
- No Windows, você precisa especificar o caminho completo para o binário `mongod`
Certifique-se de trocar `3.6` pela versão que você tem instalada.
```shell
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
```
> Dica:
> Você pode evitar de ter que iniciar o MongoDB toda hora instalando-o como um _background service_.
> Você pode [aprender mais sobre isso na documentação sobre seu respectivo sistema operacional](https://docs.mongodb.com/manual/administration/install-community/)
### _Seed_: popule o banco de dados
Agora, vamos popular o banco de dados. Neste passo, vamos rodar o comando abaixo que
irá preencher o servidor MongoDB com alguns _data-sets_ iniciais que são necessários para outros serviços. Isso inclui alguns _schemas_, dentre outras coisas.
> Nota do Tradutor: nesta seção, é utilizado o termo _seed_. Quando se trata de banco de dados, _seed_ ou semente é um conjunto de configurações iniciais criadas para popular o banco de dados. Isso pode incluir entidades, relacionamentos e um conjunto de dados inicial. Então, o verbo _to seed_ foi substituído por "popular o banco de dados".
```shell
npm run seed
```
### Inicie o _freeCodeCamp client application_ e a _API server_
Agora você pode iniciar o servidor da API e a aplicação cliente.
```shell
npm run develop
```
Este único comando irá iniciar todos os serviços, incluindo a API e o cliente disponíveis para você trabalhar.
Agora abra um _browser_ e visite <http://localhost:8000>. Se a aplicação carregar, parabéns! –_you're all set_.
> Dica:
>
> O servidor da API é aberto na porta 3000 em `http://localhost:3000`
> A aplicação Gatsby é aberta na porta 8000 em `http://localhost:8000`
O que significa que, se você visitar <http://localhost:3000/explorer> você deveria ver quais APIs temos.
Parabéns 🎉! Agora você tem uma cópia da plataforma de aprendizado do freeCodeCamp completinha e rodando na sua máquina local.
## Breve referência de comandos para trabalhar localmente
[Aqui está uma breve referência](/docs/README.md) de uma lista de comandos que você pode precisar quando estiver rodando localmente:
## Fazer alterações locais ao seu clone de freeCodeCamp
> Nota do Tradutor: esta seção utiliza vários termos relacionados ao Git em geral, que não foram traduzidos. Por exemplo: _master, origin, branch, fork, rebase, upstream_.
Assim, você pode alterar arquivos e "commitar" suas mudanças.
Siga estes passos:
1. Verifique se você está na _branch_`master`
```shell
git status
```
Você deve ter uma saída da forma:
```shell
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
```
Se vocẽ não está na `master` ou se seu diretório não está limpo, ou seja, se há alterações em seu diretório, resolva as mudanças de arquivo/_commits_ e dê _checkout_ para a _branch_`master`:
```shell
git checkout master
```
2. Depois, você deve dar `rebase` da `upstream`.
Este passo **irá sincronizar as últimas alterações** do repositório principal do freeCodeCamp. É importante que você dê _rebase_ frequetemente, para evitar conflitos posteriores.
```shell
git pull --rebase upstream master
```
Opcionalmente, você pode dar _push_ na _branch_ de volta à _origin_, para que você um histórica limpo em seu _fork_ no GitHub.
```shell
git push origin master --force
```
3. Agora, você deve criar uma nova _branch_
Trabalhar em _branches_ separadas para cada _issue_ te ajuda a manter sua cópia local limpa. Você nunca deve trabalhar na `master`. Isso pode causar conflitos na sua cópia do freeCodeCamp e talvez seja necessário iniciar tudo novamente, criando um novo _clone_ ou _fork_.
Verifique se está na `master` como explicado anteriormente e crie uma nova _branch_ a partir dali:
```shell
git checkout -b fix/update-guide-for-xyz
```
O nome da sua _branch_ deve começar com `fix/`, `feat/`, etc. Evite usar números de _issue_ em _branches_. Os nomes de _branches_ devem ser curtos, significativos e únicos.
Alguns bons nomes de _branch_ são:
```md
fix/update-challenges-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-in-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. Agora, você pode trabalhar editando páginas e código no seu editor de texto favorito.
5. Uma vez que você está feliz com suas alterações, você deve (opcionalmente) rodar o freeCodeCamp localmente para verificar suas mudanças.
6. Certifique-se de corrigir quaisquer erros, e verifique a formatação de suas mudanças. Nós temos um _style guide_ para os Guias e Desafios de Código.
7. Agora, verifique e confirme os arquivos que você quer atualizar
```shell
git status
```
Este comando deve mostrar uma lista arquivos `unstaged` que você editou.
```shell
On branch feat/documentation
Your branch is up to date with 'upstream/feat/documentation'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
8. Adicione suas mudanças à _staging area_ e faça um _commit_.
Este passo deve mostrar apenas os arquivos que você alterou ou adicionou. Você pode dar um _reset_, e retornar ao estado original arquivos que você não pretendia alterar.
```shell
git add path/to/my/changed/file.ext
```
Ou, alternativamente, você pode adicionar todos os arquivos `unstaged` para a _staging area_
```shell
git add .
```
Apenas os arquivos que foram movidos para a _staging area_ serão adicionados quando você fizer um _commit_.
```shell
git status
```
Saída:
```shell
On branch feat/documentation
Your branch is up to date with 'upstream/feat/documentation'.
Agora você pode _commitar_ suas mudanças com uma mensagem curta, como:
```shell
git commit -m "fix: my short commit message"
```
Alguns exemplos:
```md
fix: update guide article for Java - for loop
feat: add guide article for alexa skills
```
Opcional:
Nós recomendamos fortemente que faça uma mensagem de commit convencional. Isso é uma boa prático que você pode observar em alguns repositórios _Open Source_ mais populares. Como desenvolvedor, isso te encoraja a seguir algumas práticas padrão.
Alguns exemplos de mensagens de _commit_ convencionais:
```md
fix: update HTML guide article
fix: update build scripts for Travis-CI
feat: add article for JavaScript hoisting
docs: update contributing guidelines
```
Mantenha as mensagens curtas, não mais do que 50 caractéres. Você pode sempre adicionar informações na descrição da mensagem de _commit_.
Isso não toma nenhum tempo adicional comparado à mensagens não convencionais como 'update file' or 'add index.md'
Você pode aprender mais sobre [aqui](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
9. Se você perceber que precisa editar um arquivo ou atualizar a mensagem do _commit_ depois de ter feito o _commit_, você pode fazer isso com o comando:
```shell
git commit --amend
```
Este comando irá abrir o editor de texto padrão como `nano` ou `vi` onde você pode editar o título mensagem de _commit_ e adicionar/editar a descrição.
10. Agora você pode dar _push_ nas suas alterações para o seu repositório _fork_.
```shell
git push origin branch/name-here
```
## Fazendo um _Pull Request_ (PR)
1. Uma vez que suas alterações foram enviadas, uma notificação aparecerá na página do seu repositório _fork_ para criar uma _pull request_.
2. Por padrão, todas as _pull requests_ devem se referir ao repositório principal do freeCodeCamp, `master` branch.
Ceritifique-se que o _Base Fork_ está apontando para freeCodeCamp/freeCodeCamp ao crair uma _Pull Request_.\*\*
3. Envie a _pull request_ da sua _branch_ para a _branch_`master` do freeCodeCamp.
4. No corpo do seu PR inclua um sumário detalhando quais mudanças você fez e por que.
- Será apresentado a você um _template_ de _pull request_. É um checklist de coisas que você deveria ter feito antes de abrir um _pull request_.
- Preencha com detalhes como lhe convir. Essa informação será revisada e então será decidido se seu _pull request_ será aceito ou não.
- Se o PR foi criado para corrigir um problema ou _bug_ existente então, ao fim da descrição da _pull request_, adicione a _keyword_`closes` e #xxxx (onde xxxx
é o número da _issue_). Exemplo: `closes #1337`. Isso informa ao GitHub para fechar automaticamente a _issue_ existente, se o PR for _accepted and merged_.
5. Indique se você testou numa cópia local do site ou não.
Isso é muito importante quando você está fazendo alterações que não são copiar/editar arquivos Markdown. Por exemplo, mudanças de CSS ou código JavaScript, etc.
## Tenha seu PR aceito
## Obtendo ajuda
Se você está com dificuldades e precisa de ajuda, deixa-nos saber ao perguntar na [categoria 'Contributors' em nosso fórum](https://www.freecodecamp.org/forum/c/contributors) ou o [Chat de Contribuidores](https://gitter.im/FreeCodeCamp/Contributors) no Gitter.
Deve haver um erro no console do seu _browser_ ou no Bash / Terminal / Linha de Comando que pode ajudar a identificar o problema.
### _Troubleshooting_: solucionando problemas
Se sua aplicação roda, mas você está encontrando problemas com a interface em si, por exemplo, se as fontes não estão carregando ou se o editor de código não está aparecendo apropriadamente, você pode tentar os seguintes passos ao menos uma vez:
