Cap. 20 - Node.js about eloquente-javascript

[lucasfcosta]

Posso traduzir esse?

[ericdouglas]

Com certeza @lucasfcosta ! 😄

[lucasfcosta]

@ericdouglas eric, só pra avisar, comecei a traduzir, mas só traduzi alguns dos primeiros trechos, nas próximas duas semanas acho que não vou estar por aí, só pra deixar ciente, valeu!

[ericdouglas]

Perfeito @lucasfcosta ! Irei retomar as traduções em breve também, mudei de cidade então ainda estou no período de adaptação 😄

[]'s

[gabrielfgularte]

Tá livre? Posso pegar?

[joaostein]

@lucasfcosta -- Tudo certo por aí? Como estão as coisas? Se estiver complicado, poderíamos passar o capítulo para o @gabrielfgularte, já que ele se mostrou interessado, o que acha?

[gabrielfgularte]

@joaostein Já comecei a tradução aqui, qualquer coisa, se o @lucasfcosta voltar antes de eu acabar, a gente vê como fica. ;)

Qualquer coisa, o andamento da minha tradução está aqui: https://github.com/gabrielfgularte/eloquente-javascript/blob/master/chapters/20-nodejs.md

[joaostein]

perfeito

[gabrielfgularte]

@joaostein E agora, como continuo a tradução? Pq o @ewertonorg corrigiu uma parada no fork dele, fez o PR pra cá, vocês deram merge e ficou bom. Mas no meu fork não tem essa correção dele. O que fazer nessa situação? Continuo traduzindo deixando o erro que ele já corrigiu errado? Ou corrijo também, e deixa dar conflito caso haja algum?

[rands0n]

@gabrielfgularte No seu caso, você tem que atualizar o seu PR de acordo com o original. Faz o seguinte:

Pela linha de comando, adiciona mais um remote no seu repositório, assim:

$ git remote add ejs https://github.com/braziljs/eloquente-javascript.git

Depois disso cria uma branch:

$ git checkout -b ejs

Faz o Pull das modificações de acordo com o novo remote:

$ git pull origin ejs

Ai depois de tudo isso você volta pra branch master e faz o merge da branch ejs. Com o merge as modificações do @ewertonorg estará no seu repositório. Depois pode excluir a branch ejs também :)

[joaostein]

basicamente o processo que o @randsonjs descreveu.

Como você está trabalhando direto no master, para fazer o merge você não precisa necessariamente dar pull em um branch novo para depois fazer o merge. Se você adicionar o remote ejs (eu normalmente coloco o nome de upstream) e der um git pull ejs master, ele irá atualizar e informará caso haja conflito.

O meu workflow é mais o menos assim:

1. git checkout -b c0xr0y -- onde _c_ é capítulo, _x_ é o número do capítulo, _r_ é review e _y_ é o número da review
2. Começo a trabalhar nesse branch até o momento que tenho material suficiente para fazer um pull request, então faço git push origin c0xr0y:c0xr0y para subir para o meu fork criando um branch chamado c0xr0y no repo do github do meu fork.
3. Com esse branch novo online e as alterações, eu faço um pull request normal e na descrição eu adiciono a referência a issue original (usando #número-da-issue), pois fica mais fácil visualizar o histórico.
4. Depois que as alterações forem "mergeadas" no repositório oficial, eu dou um git checkout master para ir para o master e em seguida git pull upstream master (se tiver nomeado como ejs só substituir o nome do remote) para atualizar o meu master em relação ao master oficial, e depois volto para o passo número 1, incrementando o valor de _y_.

PS. Eu gosto de manter meus branches para controle até terminar o capítulo, pois eu fico com o histórico certinho de tudo que eu fiz em ordem numérica crescente, só que isso não é necessário.

PS2. (cc @ericdouglas) Se fizermos um guia de contribuição, poderíamos colocar algumas instruções similares a essas.

[gabrielfgularte]

Muito bom! @joaostein e @randsonjs . Muito obrigado!

[ericdouglas]

Com certeza @joaostein, isso ajuda e muito! O @SauloSilva vai iniciar o CONTRIBUTING.md

[ericdouglas]

Vou colocar esse capítulo na branch gh-pages.