mirror/pcottle.learnGitBranching
1
0
Fork 0
mirror of https://github.com/pcottle/learnGitBranching.git synced 2025-08-30 22:59:38 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #231 from thotypous/master

Browse source 
Preliminary translation into Brazilian Portuguese
This commit is contained in:
Peter Cottle 2014-12-25 11:08:55 -08:00
commit 53bff91a4a
41 changed files with 2396 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

59
src/levels/remote/clone.js
View file

@ -7,6 +7,7 @@ exports.level = {
"de_DE": "Clone Einführung",
"ja" : "Clone入門",
"es_AR": "Introducción a clone",
"pt_BR": "Introdução à clonagem",
"zh_CN": "介绍 Clone",
"zh_TW": "介紹 clone"
},
@ -17,6 +18,7 @@ exports.level = {
"ja" : "単にgit clone!",
"zh_CN": "只要 git clone!",
"es_AR": "Simplemente hacé git clone!",
"pt_BR": "Basta fazer um git clone!",
"zh_TW": "只要 git clone 就好了"
},
"startDialog": {
@ -191,6 +193,63 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Remotos no Git",
"",
"Repositórios remotos não são algo muito complicado. Nos dias atuais de computação em nuvem, seria fácil pensar que existiria muita mágica por trás dos remotos do Git, mas não é o caso -- eles são na verdade apenas cópias do seu repositório em outro computador. Você pode geralmente comunicar-se com esse outro computador por meio da Internet, o que permite que você transfira commits de um lado para o outro.",
"",
"Tendo dito isto, repositórios remotos tem uma série de propriedades interessantes:",
"",
"- Primeiro e antes de tudo, repositórios remotos servem como um ótimo backup! Repositórios Git locais possuem a habilidade de restaurar um arquivo para um estado anterior (como você sabe), mas toda a informação está guardada localmente. Tendo cópias do seu repositório Git em outros computadores, mesmo se você perder todos os seus dados locais, ainda terá como recomeçar do mesmo ponto de onde você tinha parado.",
"",
"- Ainda mais importante, repositórios remotos tornam o desenvolvimento uma atividade social! Agora que uma cópia do seu projeto está hospedada em outro lugar, seus amigos podem contribuir para o seu projeto (ou obter as suas últimas alterações) de uma forma bastante simples.",
"",
"Está se tornando bastante popular o uso de websites para visualizar a atividade em repositórios (como o [Github](https://github.com/) ou o [Phabricator](http://phabricator.org/)), mas o recurso de repositórios remotos _sempre_ serve como mecanismo base para essas ferramentas. Então é importante entender como ele funciona!"
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Nosso comando para criar remotos",
"",
"Até este ponto, o Learn Git Branching focou em ensinar o básico a respeito de trabalho em repositórios _locais_ (branch, merge, rebase, etc). Entretanto, agora que queremos aprender como repositórios remotos funcionam, precisamos de um comando para configurar o ambiente para essas lições. Esse comando será o `git clone`.",
"",
"Tecnicamente, o `git clone` do mundo real é um comando que se usa para criar cópias _locais_ de repositório remotos (do GitHub para o seu computador, por exemplo). Todavia, por motivos logísticos, nós usaremos esse comando de uma forma um pouco diferente no Learn Git Branching -- aqui o `git clone` criará um repositório remoto a partir do repositório local. Certamente, esse comportamento é exatamente o oposto do comando real, mas apesar disso ele ajuda a formar a conexão mental entre a clonagem e a forma como repositórios remotos funcionam, então vamos usá-lo dessa forma mesmo por enquanto.",
""
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vamos começar devagar e apenas olhar como um repositório remoto se parece na nossa visualização.",
""
],
"afterMarkdowns": [
"Aqui está ele! Agora temos um repositório remoto do nosso projeto. Ele é muito parecido exceto por algumas mudanças visuais para tornar a distinção factível -- nas tarefas a seguir veremos como compartilhar trabalho entre esses repositórios."
],
"command": "git clone",
"beforeCommand": ""
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para completar este nível, simplesmente chame o comando `git clone`. Você aprenderá algo de verdade somente nas próximas lições."
]
}
}
]
},
"zh_TW": {
"childViews": [
{

56
src/levels/remote/fakeTeamwork.js
View file

@ -8,6 +8,7 @@ exports.level = {
"de_DE": "Teamarbeit simulieren",
"ja" : "擬似チームワーク",
"es_AR": "Simulando el trabajo en equipo",
"pt_BR": "Simulando trabalho em equipe",
"zh_CN": "模拟团队合作",
"zh_TW": "模擬團隊合作"
},
@ -17,6 +18,7 @@ exports.level = {
"de_DE": "Nicht vergessen, du kannst angeben wieviele Commits simuliert werden sollen.",
"ja" : "擬似で作成するコミット数を指定できるのをお忘れなく",
"es_AR": "Acordate que podés especificar cuántos commits simular",
"pt_BR": "Lembre-se que você pode especificar quantos commits quer simular",
"zh_CN": "记住为fake中的commit指定数量",
"zh_TW": "你要記得指定要送多少個 commit 出去"
},
@ -183,6 +185,60 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Simulando colaboração",
"",
"Neste ponto, temos uma pequena dificuldade -- para algumas das lições a seguir, precisaremos ensinar como fazer pull de mudanças que foram introduzidas no repositório remoto.",
"",
"Isso significa que precisaremos essencialmente \"fingir\" que o repositório remoto foi atualizado por algum de seus colegas / amigos / colaboradores, algumas vezes em um ramo específico ou com um certo número de commits.",
"",
"Para esta finalidade, criamos o comando fictício `git fakeTeamwork`! Ele é bastante auto-explicativo, vejamos uma demonstração..."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"O comportamento padrão do `fakeTeamwork` é simplesmente fazer aparecer um commit no master"
],
"afterMarkdowns": [
"Aqui vamos nos -- o repositório remoto foi atualizado com um novo commit, e ainda não baixamos esse commit porque não executamos um `git fetch`."
],
"command": "git fakeTeamwork",
"beforeCommand": "git clone"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Você também pode especificar o número de commits ou o ramo, anexando-os ao comando"
],
"afterMarkdowns": [
"Com um único comando, nós simulamos um colega enviando 3 commits para o ramo `foo` do repositório remoto"
],
"command": "git fakeTeamwork foo 3",
"beforeCommand": "git branch foo; git clone"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Os níveis posteriores serão mais difíceis, então estamos pedindo um pouco mais de você neste nível.",
"",
"Vá em frente e crie um repositório remoto (chamando `git clone`), simule algumas mudanças no repositório remoto, commite no repositório local, e então faça um pull das mudanças que haviam sido simuladas. É como se fossem várias lições em uma só!"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

75
src/levels/remote/fetch.js
View file

@ -8,6 +8,7 @@ exports.level = {
"de_DE": "Git Fetch",
"ja" : "Git Fetch",
"es_AR": "git fetch",
"pt_BR": "Git Fetch",
"zh_CN": "Git Fetch",
"zh_TW": "git fetch"
},
@ -17,6 +18,7 @@ exports.level = {
"de_DE": "Einfach git fetch ausführen!",
"ja" : "単にgit fetchを実行！",
"es_AR": "Simplemente ¡hacé git fetch!",
"pt_BR": "Simplesmente chame git fetch!",
"zh_CN": "只要运行 git fetch 命令!",
"zh_TW": "只要下 git fetch 指令"
},
@ -240,6 +242,79 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Git Fetch",
"",
"Trabalhar com remotos no Git, no final das contas, se resume a transferir dados _de_ e _para_ outros repositórios. Desde que possamos enviar commits para um lado e para o outro, poderemos compartilhar qualquer tipo de atualização que seja gerenciada pelo Git (e portanto compartilhar trabalho, novos arquivos, novas ideias, cartas de amor, etc).",
"",
"Nesta lição vamos aprender como baixar dados _de_ um repositório remoto -- o comando para isso é convenientemente chamado de `git fetch`.",
"",
"Você perceberá que conforme atualizarmos a representação do repositório remoto, nossos ramos _remotos_ atualizar-se-ão para refletir essa nova representação. Isso tem a ver com o que vimos na lição anterior sobre ramos remotos"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Antes de entrar nos detalhes do `git fetch`, vejamo-no em ação! Aqui temos um repositório remoto que contém dois commits que nosso repositório local não possui."
],
"afterMarkdowns": [
"Lá vamos nós! Os commits `C2` e `C3` foram baixados para o nosso repositório local, e nosso ramo remoto `o/master` foi atualizado para refletir esse fato."
],
"command": "git fetch",
"beforeCommand": "git clone; git fakeTeamwork 2"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### O que o fetch faz",
"",
"O `git fetch` realiza dois passos principais, e somente estes dois passos principais. Ele:",
"",
"* Baixa os commits que o repositório remoto possui mas que estão faltando no repositório local, e...",
"* Atualiza a referência para a qual os ramos remotos (por exemplo, `o/master`) estão apontando",
"",
"O `git fetch` essencialmente faz com que nossa representação _local_ do repositório remoto fique sincronizada com a forma com que o repositório remoto _de fato_ se parece (naquele momento).",
"",
"Se você lembrar da lição anterior, nós dissemos que os ramos remotos refletem o estado dos repositórios remotos _desde a última vez_ na qual você falou com esses repositórios. O `git fetch` é a única forma de falar com esses repositórios remotos! Espero que a conexão entre os ramos remotos e o `git fetch` esteja clara agora.",
"",
"O `git fetch` geralmente conversa com o repositório remoto por meio da Internet (usando um protocolo como `http://` ou `git://`).",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### O que o fetch NÃO faz",
"",
"O `git fetch`, no entanto, não muda nada do estado _local_ do repositório. Ele não atualiza o seu ramo `master` nem muda nada na forma como o seu sistema de arquivos está no momento.",
"",
"É importante entender isso, pois muitos desenvolvedores pensam que executar `git fetch` fará com que o trabalho local reflita o estado do repositório remoto. Ele pode até baixar todos os dados necessários para fazê-lo, mas ele _não_ muda de fato nenhum dos arquivos locais. Vamos aprender comandos para fazê-lo nas lições a seguir :D",
"",
"No final das contas, você pode pensar no `git fetch` como um passo de download."
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para terminar este nível, simplesmente execute `git fetch` e baixe todos os commits!"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

125
src/levels/remote/fetchArgs.js
View file

@ -8,6 +8,7 @@ exports.level = {
"zh_CN": "Fetch 的参数",
"zh_TW": "fetch 的參數",
"es_AR": "Parámetros de fetch",
"pt_BR": "Parâmetros do fetch",
"de_DE": "Optionen für Fetch",
"ja" : "Fetchの引数"
},
@ -17,6 +18,7 @@ exports.level = {
"zh_CN": "注意下提交对象的id是如何交换的! 你可以通过`help level`再次切到幻灯片!",
"zh_TW": "注意 commit 的 id 是怎麼被交換的！你可以透過 `help level` 來閱讀對話視窗！",
"es_AR": "¡Prestá atención a cómo podrían haberse invertido los ids de los commits! Podés volver a leer toda la lección usando \"help level\"",
"pt_BR": "Preste atenção em como os identificadores dos commits podem ter trocado! Você pode ler os slides novamente com \"help level\"",
"de_DE": "Beachte wie die Commit IDs getauscht wurden! Du kannst den Einführungsdialog mit \"help level\" erneut anzeigen",
"ja" : "コミットIDの入れ替わりに注意！スライドを復習するには`help level`を実行"
},
@ -390,6 +392,129 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Parâmetros do git fetch",
"",
"Então acabamos de aprender tudo sobre os parâmetros do git push, inclusive sobre esse parâmetro bacana chamado `<lugar>`, e até mesmo sobre colon refspecs (`<origem>:<destino>`). Será que poderíamos aplicar todo esse conhecimento também ao `git fetch`?",
"",
"Você adivinhou! Os parâmetros do `git fetch` são na verdade *muito, muito* similares aos do `git push`. Trata-se do mesmo tipo de conceito, só que aplicado na direção oposta (já que agora é um download em vez de um upload).",
"",
"Vamos aos conceitos um por vez..."
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### O parâmetro `<lugar>`",
"",
"Se você passar um lugar ao git fetch, como no seguinte comando:",
"",
"`git fetch origin foo`",
"",
"O Git vai ao ramo remoto `foo` e pega todos os commits que não estão presentes localmente, jogando-os no ramo local `o/foo`.",
"",
"Vejamo-lo em ação (só para refrescar a memória)."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Especificando um lugar..."
],
"afterMarkdowns": [
"Baixamos só os commits de `foo` e colocamos em `o/foo`"
],
"command": "git fetch origin foo",
"beforeCommand": "git branch foo; git clone; git fakeTeamwork foo 2"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Você pode estar se perguntando -- por que o Git colocou os commits no ramo remoto `o/foo` em vez de simplesmente jogá-los no meu ramo local `foo`? Eu pensei que o parâmetro fosse um `<lugar>` que existisse tanto no repositório local como no remoto?",
"",
"Bem, o Git tem uma exceção especial neste caso, porque pode ser que exista trabalho seu no ramo local `foo` que você não queira bagunçar!! Esse fato é relacionado com o abordado na lição anterior sobre o `git fetch` -- ele não atualiza ramos locais não-remotos, ele apenas baixa os commits (de forma que você possa inspecioná-los e/ou realizar um merge posteriormente).",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"\"Bem, neste caso, o que acontece se eu definir explicitamente tanto a origem como o destino, com `<origem>:<destino>`?\"",
"",
"Se você estiver apaixonado o suficiente para baixar commits *diretamente* em um ramo local, então sim, você pode especificar esse comportamento com um colon refspec. Você só não pode baixar commits em um ramo que esteja atualmente em checkout, mas se não estiver, o Git permitirá o fetch.",
"",
"Aqui está o único detalhe -- `<origem>` agora é uma referência *remota* e `<destino>` é uma referência *local* de onde colocar esses commits. É exatamente o oposto do git push, e realmente faz sentido, já que estamos transferindo os dados na direção oposta!",
"",
"Tendo dito isto, desenvolvedores raramente fazem isso na prática. Estou introduzindo essa informação mais como uma forma de conceitualizar a forma como `fetch` e `push` são tão similares, apenas em direções opostas."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vejamos essa loucura em ação:"
],
"afterMarkdowns": [
"Wow! Viu, o Git entendeu o `foo~1` como um lugar de origin e baixou os commits para o ramo local `bar`. Veja como `foo` e `o/foo` não foram atualizados, já que especificamos outro destino."
],
"command": "git fetch origin foo~1:bar",
"beforeCommand": "git branch foo; git clone; git branch bar; git fakeTeamwork foo 2"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"E se o destino não existir antes de eu executar o comando? Vamos rever o último slide, mas em uma situação na qual o `bar` não existe de antemão."
],
"afterMarkdowns": [
"Viu? Funciona EXATAMENTE como o git push. O Git criou o destino localmente antes do fetch, da mesma forma como o Git cria o destino (se ele não existir) no repositório remoto durante um push."
],
"command": "git fetch origin foo~1:bar",
"beforeCommand": "git branch foo; git clone; git fakeTeamwork foo 2"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Sem parâmetros?",
"",
"Se o `git fetch` não receber argumentos, ele simplesmente baixa todos os commits do repositório remoto em todos os ramos remotos..."
],
"afterMarkdowns": [
"Bastante simples, mas importante de rever ao menos uma vez."
],
"command": "git fetch",
"beforeCommand": "git branch foo; git clone; git fakeTeamwork foo; git fakeTeamwork master"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Ok, chega de conversa! Para completar este nível, faça fetch apenas dos commits especificados na visualização do objetivo. Capriche nos comandos!",
"",
"Você terá de especificar tanto a origem como o destino em ambos os comandos de fetch. Preste atenção na janela de visualização, já que os identificadores podem trocar!"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

145
src/levels/remote/fetchRebase.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "分散的历史",
"zh_TW": "diverged history",
"es_AR": "Historia divergente",
"pt_BR": "Histórico divergente",
"de_DE": "Abweichende History",
"fr_FR": "Historique divergent",
"ja" : "履歴の分岐"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "检出可视化目标中的顺序",
"zh_TW": "確認視覺化的目標中的順序",
"es_AR": "Prestá atención al orden del objetivo",
"ot_BR": "Preste atenção na ordem da visualização do objetivo",
"de_DE": "Beachte die Reihenfolge in der Zieldarstellung",
"ja" : "ゴールのビジュアライズの順番を参照",
"fr_FR": "regardez l'ordre dans la fenêtre de visualisation d'objectif"
@ -450,6 +452,149 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Histórico Divergente",
"",
"Até o momento vimos como fazer `pull` de commits dos outros e como fazer `push` de nossas próprias mudanças. Parece ser tão simples, como será que as pessoas ficam tão confusas?",
"",
"A dificuldade aparece quando o histórico do repositório *diverge*. Antes de discutir os detalhes disso, vejamos um exemplo...",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Imagine que você clonou um repositório na segunda-feira e começou a trabalhar em uma funcionalidade nova. Na sexta-feira você está pronto para publicar a funcionalidade -- mas, ah não! Seus colegas escreveram um bocado de código durante a semana, tornando a sua funcionalidade obsoleta. Eles também publicaram esses commits no repositório remoto que vocês compartilham, então agora o *seu* trabalho é baseado em uma versão *antiga* do projeto, que não é mais relevante.",
"",
"Neste caso, o comando `git push` é ambíguo. Se você executar `git push`, será que o Git deveria tratar o repositório remoto como se ele ainda estivesse no estado da segunda-feira? Será que ele deveria tentar adicionar seu código dentro do repositório sem tentar remover o código novo? Ou será que ele deveria simplesmente ignorar suas mudanças totalmente, já que elas estão obsoletas?",
"",
"Devido à grande ambiguidade que surge neste tipo de situação (quando a história divergiu), o Git não permite que você faça `push` das suas mudanças. Ele, de fato, força você a incorporar o último estado do repositório remoto antes de conseguir compartilhar o seu trabalho."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Chega de conversa! Vejamos essa situação na prática"
],
"afterMarkdowns": [
"Viu? Nada aconteceu porque o comando falhou. O `git push` falha porque o commit mais recente (`C3`) é baseado no remoto em `C1`. Como o remoto foi atualizado no meio tempo, o Git rejeita o push"
],
"command": "git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Como resolver essa situação? É fácil, tudo que você precisa fazer é basear seu trabalho na versão mais recente do ramo remoto.",
"",
"Existem algumas maneiras de fazer isso, mas a mais direta é mover o seu trabalho usando rebase. Vamos em frente, ver como isso é feito."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Agora se nós fizermos um rebase antes do push..."
],
"afterMarkdowns": [
"Boom! Nós atualizamos a representação local do repositório remoto com `git fetch`, fizemos rebase do nosso trabalho para refletir as novas mudanças no repositório remoto, e então enviamos nossas mudanças com `git push`"
],
"command": "git fetch; git rebase o/master; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Será que existem outras formas de compartilhar meu trabalho quando o repositório remoto tiver sido atualizado? Claro! Vamos fazer a mesma tarefa usando `merge` em vez de `rebase`.",
"",
"Embora o `git merge` não mova o seu trabalho (em vez disso, ele cria um commit de merge), ele é uma forma de contar ao Git que você incorporou todas as mudanças do repositório remoto. Isso acontece porque o ramo remoto passa a ser um *ancestral* do seu próprio ramo, significando que o seu commit reflete todos os commits contidos no ramo remoto.",
"",
"Vejamos uma demonstração..."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Agora se fizermos merge em vez de rebase ..."
],
"afterMarkdowns": [
"Boom! Atualizamos nossa representação local do repositório remoto com `git fetch`, fizemos *merge* do novo trabalho com o nosso (para refletir as novas mudanças no repositório remoto), e então fizemos push deles com `git push`"
],
"command": "git fetch; git merge o/master; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Incrível! Existe alguma forma de fazer isso sem digitar tantos comandos?",
"",
"É claro -- você já conhece o `git pull` e ele é simplesmente um atalho para um fetch e um merge. Convenientemente, entretanto, o comando `git pull --rebase` é uma abreviação para um fetch e um rebase!",
"",
"Vejamos esses dois comandos em ação."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Primeiro com `--rebase`..."
],
"afterMarkdowns": [
"Mesma coisa que antes! Porém muito mais curto."
],
"command": "git pull --rebase; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"E agora com o `pull` normal"
],
"afterMarkdowns": [
"De novo, exatamente como antes!"
],
"command": "git pull; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Esse fluxo de trabalho de fazer fetch, rebase/merge, e push é bastante comum. Em lições futuras vamos examinar versões mais complicadas desses fluxos de trabalho, mas por enquanto vamos tentar o seguinte.",
"",
"Para resolver este nível, faça o seguinte:",
"",
"* Clone o repositório",
"* Simule trabalho de seus colegas (1 commit)",
"* Faça um commit seu (1 commit)",
"* Publique seu trabalho usando *rebase*"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

47
src/levels/remote/mergeManyFeatures.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "和远端合并",
"zh_TW": "merge with remotes",
"es_AR": "Mergeando con los remotos",
"pt_BR": "Merge com remotos",
"de_DE": "Änderungen vom Remote zusammenführen",
"ja" : "リモートとのmerge",
"fr_FR": "Fusionner avec les branches distantes"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "注意目标树!",
"zh_TW": "注意最後要完成的目標！",
"es_AR": "¡Prestá atención al árbol final!",
"pt_BR": "Preste atenção na árvore do objetivo!",
"de_DE": "Beachte den Ziel-Baum!",
"ja" : "ゴールツリーに注意！",
"fr_FR": "Respectez l'arbre représentant l'objectif !"
@ -157,6 +159,51 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Por que não um merge?",
"",
"Para enviar novas atualizações ao repositório remoto, tudo que você precisa é *incorporar* as últimas mudanças ali presentes. Isso significa que você pode tanto fazer um rebase *quanto* um merge no ramo remoto (ex. `o/master`).",
"",
"Então, se você pode escolher qualquer um desses métodos, por que as lições focaram no rebase até o momento? Por que não demos nenhum amor ao `merge` quando trabalhamos com repositórios remotos?",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Há muito debate na comunidade de desenvolvedores sobre as vantagens e desvantagens do merge e do rebase. Aqui estão os prós e contras gerais do rebase:",
"",
"Prós:",
"",
"* O rebase faz a sua árvore de commits parecer bastante limpa, já que tudo fica em uma linha reta",
"",
"Contras:",
"",
"* O rebase modifica o histórico *aparente* da sua árvore de commits.",
"",
"Por exemplo, o commit `C1` pode aparecer *depois do* `C3` após sofrer rebase. Então, fica parecendo que alguém trabalhou em `C1` apenas depois de `C3` estar completo, quando na realidade o que ocorreu foi o contrário.",
"",
"Alguns desenvolvedores adoram preservar o histórico e, portanto, preferem o merge. Outros (como eu) preferem ter uma árvore de commits limpa, obtida usando rebase. Tudo se resume ao gosto pessoal :D"
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para este nível, tente resolver o mesmo problema do nível anterior, mas usando *merge* em vez de rebase. A árvore pode ficar um pouco cabeluda, mas isso ilustra bem o nosso ponto."
]
}
}
]
},
"zh_TW": {
"childViews": [
{

61
src/levels/remote/pull.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "Git Pull",
"zh_TW": "git pull'",
"es_AR": "git pull",
"pt_BR": "Git Pull",
"de_DE": "Git Pull",
"ja" : "Git Pull",
"fr_FR": "Git pull"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "只要运行 git pull 命令!",
"zh_TW": "只要下 git pull 這個指令即可",
"es_AR": "Simplemente ¡hacé git pull!",
"pt_BR": "Basta executar git pull!",
"de_DE": "Führe einfach git pull aus.",
"ja" : "単にgit pullを実行！",
"fr_FR": "Utilisez facilement git pull !"
@ -198,6 +200,65 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Git Pull",
"",
"Agora que vimos como baixar dados de um repositório remoto com `git fetch`, vamos atualizar nosso trabalho para refletir essas mudanças!",
"",
"Há, na verdade, muitas formas de fazê-lo -- uma vez que você tenha os novos commits disponíveis localmente, você pode incorporá-los como se eles fossem commits normais em outros ramos. Isso significa que você pode executar comandos como estes a seguir:",
"",
"* `git cherry-pick o/master`",
"* `git rebase o/master`",
"* `git merge o/master`",
"* etc., etc.",
"",
"O fluxo de trabalho de executar *fetch* para baixar as mudanças remotas e depois fazer um *merge* delas é tão comum que o Git na verdade fornece um comando que faz ambas as coisas de uma vez só! Esse comando é o `git pull`."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vamos primeiro ver um `fetch` e um `merge` executados sequencialmente"
],
"afterMarkdowns": [
"Boom -- nós baixamos o `C3` com um `fetch` e então fizemos um merge desse trabalho usando `git merge o/master`. Agora o nosso ramo `master` reflete o trabalho realizado no repositório remoto (neste caso, chamado de `origin`)"
],
"command": "git fetch; git merge o/master",
"beforeCommand": "git clone; git commit; git fakeTeamwork"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"O que iria acontecer se, em vez disso, usássemos `git pull`?"
],
"afterMarkdowns": [
"Exatamente o mesmo! Isso deve tornar bem claro que `git pull` é essencialmente um caminho mais curto para executar um `git fetch` seguido de um merge de seja já qual ramo tiver sido baixado."
],
"command": "git pull",
"beforeCommand": "git clone; git commit; git fakeTeamwork"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Vamos explorar os detalhes do `git pull` mais tarde (incluindo opções e parâmetros), mas por enquanto, experimente usá-lo em sua forma mais básica.",
"",
"Lembre-se -- você também poderia resolver este nível com um `fetch` e um `merge`, mas isso lhe custaria um comando a mais :P"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

76
src/levels/remote/pullArgs.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "Pull 的参数",
"zh_TW": "pull 的參數",
"es_AR": "Parámetros de pull",
"pt_BR": "Parâmetros do pull",
"de_DE": "Optionen für Pull",
"ja" : "Pullの引数",
"fr_FR": "Arguments de pull"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "记住, 你可以通过 fetch/pull 创建本地分支",
"zh_TW": "記住，你可以透過 fetch 以及 pull 來建立一個新的 local 的 branch",
"es_AR": "Acordate de que podés crear nuevas ramas locales usando los parámetros de fetch/pull",
"pt_BR": "Lembre-se que você pode criar novos ramos locais com parâmetros de fetch/pull",
"de_DE": "Du kannst neue lokale Branches mittels fetch / pull erstellen",
"ja" : "Fetchとpullの引数を利用してローカルで新規ブランチを作成できるのをお忘れなく",
"fr_FR": "Vous pouvez aussi créer une nouvelle branche locale avec les arguments de fetch/pull"
@ -243,6 +245,80 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Parâmetros do git pull",
"",
"Agora que você sabe praticamente *tudo* que há para saber sobre parâmetros do `git fetch` e `git push`, não há praticamente nada a se abordar a respeito do git pull :)",
"",
"Isso é porque o git pull no final das contas é *realmente* apenas um atalho para um fetch seguido de um merge em seja lá o que acabou de ser baixado. Você pode pensar nele como rodar o git fetch recebendo os *mesmos* argumentos, seguido de um merge no lugar *onde* esses commits foram parar.",
"",
"Isso se aplica mesmo no caso de argumentos loucamente complicados. Vejamos alguns exemplos:"
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Aqui estão alguns comandos que são equivalente para o Git:",
"",
"`git pull origin foo` é igual a:",
"",
"`git fetch origin foo; git merge o/foo`",
"",
"E...",
"",
"`git pull origin bar~1:bugFix` é igual a:",
"",
"`git fetch origin bar~1:bugFix; git merge bugFix`",
"",
"Viu? O git pull é realmente um atalho para fetch + merge, e tudo com o que o git pull se importa é com onde os commits foram parar (o parâmetro de `destino` que ele descobre durante o fetch).",
"",
"Vejamos uma demonstração:"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Se especificarmos o lugar onde fazer o fetch, tudo acontece como antes com o fetch, mas fazemos o merge naquilo que acabou de ser baixado"
],
"afterMarkdowns": [
"Veja! Especificando `master` nós baixamos commits em `o/master` como sempre. Então fizemos um merge de `o/master` com o lugar onde estamos, *independente* daquilo que está atualmente em checkout."
],
"command": "git pull origin master",
"beforeCommand": "git clone; go -b bar; git commit; git fakeTeamwork"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Isso também funciona com origem e destino especificados? Sim, você acertou! Vejamos:"
],
"afterMarkdowns": [
"Wow, isso é MUITA coisa em um comando só. Nós criamos um novo ramo local chamado `foo`, baixamos commits do master remoto nesse ramo `foo`, e então fizemos um merge dele com o ramo atualmente em checkout, `bar`."
],
"command": "git pull origin master:foo",
"beforeCommand": "git clone; git fakeTeamwork; go -b bar; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Ok, para terminar, obtenha o estado da visualização do objetivo. Você vai precisar baixar alguns commits, criar novos ramos, e fazer merge de ramos em outros ramos, mas não deve precisar de muitos comandos para isso :P"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

45
src/levels/remote/push.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "Git Push",
"zh_TW": "git push",
"es_AR": "git push",
"pt_BR": "Git Push",
"de_DE": "Git Push",
"ja" : "Git Push",
"fr_FR": "Git push"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "push 之前你需要先 clone.",
"zh_TW": "push 之前你需要先 clone",
"es_AR": "¡Acordate que tenés que clonar antes de pushear!",
"pt_BR": "Lembre-se de clonar antes de fazer o push!",
"de_DE": "Denk dran, dass du einen Clone brauchst bevor du Pushen kannst!",
"ja" : "Pushできる前にまずレポジトリをcloneする必要があるのをお忘れなく",
"fr_FR": "Rappelez-vous que vous devez cloner avant de pouvoir faire un push !"
@ -148,6 +150,49 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Git Push",
"",
"Ok, então vimos como baixar mudanças do repositório remoto e incorporá-las à árvore local. Isso é ótimo e tal... mas como eu faço para compartilhar o _meu_ trabalho sensacional com as outras pessoas?",
"",
"Bem, a forma de subir trabalho a ser compartilhado é a oposta daquela de baixar trabalho que foi compartilhado. E qual o oposto de `git pull` (puxar)? É `git push` (empurrar)!",
"",
"O `git push` é responsável por subir as _suas_ mudanças para um repositório remoto especificado, e atualizar esse remoto para incorporar seus novos commits. Uma vez que o `git push` se completa, todos os seus amigos podem baixar o seu trabalho do repositório remoto.",
"",
"Você pode pensar no `git push` como um comando para \"publicar\" o seu trabalho. Ele tem uma série de nuances que vamos abordar em breve, mas comecemos com passos curtos...",
"",
"*Nota -- o comportamento de `git push` sem argumentos varia dependendo da configuração `push.default` do Git. O valor padrão para essa configuração depende da versão do Git que você estiver usando, mas vamos assumir o valor `upstream` nestas lições. Isso não é um grande problema, mas vale a pena verificar suas configurações antes de fazer push nos seus próprios projetos.*"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Aqui temos algumas mudanças que o repositório remoto não contém. Vamos subi-las!"
],
"afterMarkdowns": [
"Aqui vamos nós -- o repositório remoto recebeu o commit `C2`, o ramo `master` no repositório remoto foi atualizado para apontar para `C2`, e a *nossa* reflexão do remoto (`o/master`) foi atualizada também. Está tudo sincronizado!"
],
"command": "git push",
"beforeCommand": "git clone; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para completar este nível, simplesmente compartilhe dois novos commits com o repositório remoto. No entanto, segure-se no seu assento, pois estas lições estão prestes a ficar mais difíceis!"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

74
src/levels/remote/pushArgs.js
View file

@ -10,6 +10,7 @@ exports.level = {
"zh_CN": "Git push 的参数",
"zh_TW": "git push 的參數",
"es_AR": "Parámetros de git push",
"pt_BR": "Parâmetros do git push",
"de_DE": "Optionen für Git Push",
"ja" : "Git pushの引数",
"fr_FR": "Paramètres de git push"
@ -19,6 +20,7 @@ exports.level = {
"zh_CN": "你可以利用 \"objective\" 来阅读对话窗口的最后一页",
"zh_TW": "你可以利用 \"objective\" 來閱讀對話視窗的最後一頁",
"es_AR": "Siempre podés ver el último mensaje tipeando \"objective\"",
"pt_BR": "Você sempre pode rever o último slide com o comando \"objective\"",
"de_DE": "Du kannst dir die Zielsetzung des Levels immer wieder mit \"objective\" anzeigen lassen",
"ja" : "ダイアログの最後のスライドを参照するには\"objective\"を実行",
"fr_FR": "Vous pouvez toujours regarder le dernier slide des dialogues en tapant \"objective\"."
@ -240,6 +242,78 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Parâmetros do push",
"",
"Ótimo! Agora que você sabe sobre remote tracking de ramos, podemos começar a revelar um pouco do mistério por trás de como o push, o fetch e o pull funcionam. Vamos lidar com um comando por vez, mas os conceitos são bastante similares.",
"",
"Primeiro, vamos abordar o `git push`. Você aprendeu na lição sobre remote tracking que o Git descobria o repositório remoto *e* o ramo correspondente onde fazer o push olhando nas propriedades do ramo que está atualmente em checkout (verificando o ramo remoto que ele \"segue\"). Este é o comportamento quando nenhum parâmetro é especificado, mas o git push pode opcionalmente receber parâmetros na seguinte forma:",
"",
"`git push <repositório remoto> <lugar>`",
"",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Você deve estar se perguntando: o que é esse parâmetro `<lugar>`? Vamos discutir as especifidades em breve, mas vejamos primeiro um exemplo. Executar o comando:",
"",
"`git push origin master`",
"",
"pode ser traduzido para o seguinte em Português:",
"",
"*Vá ao ramo chamado \"master\" no meu repositório local, pegue todos os commits, então vá ao ramo \"master\" no repositório remoto chamado \"origin\". Coloque quaisquer commits que estiverem faltando nesse ramo, e então me diga quando estiver pronto.*",
"",
"Especificando `master` como parâmetro \"lugar\", dizemos ao Git de onde os commits *vão vir* e para onde os commits *irão*. É essencialmente o \"lugar\" onde sincronizar entre os dois repositórios.",
"",
"Tenha em mente que já que contamos ao Git tudo que ele precisa saber (especificando ambos os parâmetros), ele ignora totalmente o checkout atual!"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vejamos um exemplo especificando os argumentos. Preste atenção no commit que sofreu checkout neste exemplo."
],
"afterMarkdowns": [
"Aqui vamos nós! O `master` foi atualizado no repositório remoto, já que especificamos os parâmetros."
],
"command": "git checkout C0; git push origin master",
"beforeCommand": "git clone; git commit"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"E se eu não especificasse parâmetros? O que aconteceria?"
],
"afterMarkdowns": [
"O comando falha (como você pode ver), já que o `HEAD` não havia sofrido checkout para um ramo com propriedade de remote-tracking definida."
],
"command": "git checkout C0; git push",
"beforeCommand": "git clone; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Ok, neste nível vamos atualizar tanto o `foo` como o `master` no repositório remoto. Porém desabilitamos o comando `git checkout` para dificultar um pouco a tarefa!"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

72
src/levels/remote/pushArgs2.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "Git push 参数 2!",
"zh_TW": "git push 的參數，延伸討論！",
"es_AR": "¡Más! Parámetros de git push",
"pt_BR": "Parâmetros do git push -- expandido",
"de_DE": "Optionen für Git Push -- noch mehr!",
"ja" : "Git pushの引数 -- 拡張編!",
"fr_FR": "Arguments de git push -- toujours plus !"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "如果你失败了, 可以通过 \"show solution\" 找到解决方案 :P",
"zh_TW": "如果你失敗了，可以利用 \"show solution\" 來找到解答:P",
"es_AR": "Recordá que podés admitir tu derrota y tipear \"show solution\" para ver la solución :P",
"pt_BR": "Lembre-se que você pode admitir que foi derrotado e digitar \"show solution\" :P",
"de_DE": "Vergiss nicht dass du aufgeben kannst, indem du \"show solution\" eingibst :P",
"ja" : "降参して解説を見るには\"show solution\"を実行できるのをお忘れなく",
"fr_FR": "N'oubliez pas que vous pouvez toujours déclarer forfait avec \"show solution\" :P"
@ -231,6 +233,76 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Detalhes sobre `<lugar>`",
"",
"Lembra que na lição anterior especificamos `master` como o parâmetro lugar para o git push? Lá definimos tanto a *origem* de onde os commits viriam quanto o *destino* para onde os commits foram.",
"",
"Você pode estar se perguntando -- e se eu quisesse que a origem e o destino fossem diferentes? E se eu quisesse enviar commits do ramo local `foo` para o ramo remoto `bar`?",
"",
"Bem, infelizmente isso é impossível no Git... só brincando! Claro que é possível :)... o Git tem muita flexibilidade (até mais do que deveria).",
"",
"Veremos como fazê-lo no próximo slide..."
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para especificar tanto a origem como o destino do `<lugar>`, simplesmente juntamos os dois usando dois-pontos:",
"",
"`git push origin <origem>:<destino>`",
"",
"Isso é geralmente chamado de \"colon refspec\" (especificação de referência com dois-pontos). Refspec é só um nome extravagante para um local que o Git consiga entender (como o ramo `foo` ou mesmo `HEAD~1`)",
"",
"Uma vez que você está especificando tanto a origem como o destino independentemente, você pode ser bastante preciso nos comandos relacionados a repositórios remotos. Vejamos uma demonstração!"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Lembre-se, `origem` é qualquer lugar que o Git possa entender:"
],
"afterMarkdowns": [
"Uau! Esse comando é bastante viajado, mas ele faz sentido -- o Git entendeu a referência `foo^`, enviou quaisquer commits que não estavam presentes no repositório remoto, e então atualizou o destino."
],
"command": "git push origin foo^:master",
"beforeCommand": "git clone; go -b foo; git commit; git commit"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"E se o destino para o qual você quiser fazer push não existir? Sem problemas! Dê um nome de ramo e o Git criará o ramo no repositório remoto para você."
],
"afterMarkdowns": [
"Doce, isso é muito bom :D"
],
"command": "git push origin master:newBranch",
"beforeCommand": "git clone; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para este nível, tente chegar ao estado do objetivo mostrado na visualização, e lembre-se do formato:",
"",
"`<origem>:<destino>`"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

55
src/levels/remote/pushManyFeatures.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "你随时都可以使用 undo/reset 命令.",
"zh_TW": "你隨時都可以使用 undo 或 reset 指令。",
"es_AR": "Acordate que siempre podés usar los comandos reset y undo",
"pt_BR": "Lembre-se que você sempre pode usar undo ou reset",
"de_DE": "Denk dran, du kannst immer undo oder reset benutzen, um deine Befehle zurück zu nehmen.",
"ja" : "undoやresetコマンドをいつでも使用することができるのをお忘れなく",
"fr_FR": "Rappelez-vous que vous pouvez toujours utiliser les commandes undo et reset."
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "Push Master!",
"zh_TW": "push master！",
"es_AR": "¡Push Master!",
"pt_BR": "Push Master!",
"de_DE": "Push Master!",
"ja": "Push Master!",
"fr_FR": "Maître du push !"
@ -181,6 +183,59 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Merge de ramos de funcionalidades",
"",
"Agora que você está confortável com fetch, pull e push, vamos colocar essas habilidades em teste com um novo fluxo de trabalho.",
"",
"É comum para desenvolvedores de grande projetos fazer todo o trabalho em ramos de funcionalidades (fora do `master`) e então integrar esse trabalho uma única vez quando ele estiver pronto. Isso é similar à lição anterior (onde ramos laterais eram enviados ao repositório remoto), mas introduzimos mais um passo.",
"",
"Alguns desenvolvedores só fazem push e pull quando no ramo `master` -- desta forma o `master` sempre se mantém atualizado com aquilo que está no ramo remoto (`o/master`).",
"",
"Então, para este fluxo de trabalho, combinaremos duas coisas:",
"",
"* Integrar ramos de funcionalidade no `master`, e",
"* Realizar push e pull do repositório remoto"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vamos refrescar a memória sobre como atualizar o `master` e enviar trabalho."
],
"afterMarkdowns": [
"Nós executamos dois comandos aqui que:",
"",
"* Fizeram rebase de nosso trabalho nos novos commits do repositório remoto, e",
"* Publicaram nosso trabalho no repositório remoto"
],
"command": "git pull --rebase; git push",
"beforeCommand": "git clone; git commit; git fakeTeamwork"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Esse nível é um pouco pesado -- aqui está a linha geral de como resolver:",
"",
"* Há três ramos de funcionalidades -- `side1`, `side2` e `side3`",
"* Queremos enviar cada uma dessas funcionalidades, em ordem, para o repositório remoto",
"* O repositório remoto foi atualizado desde então, então também precisaremos incorporar o trabalho realizado lá",
"",
":O intenso! boa sorte, completar este nível é um grande passo."
]
}
}
]
},
"zh_TW": {
"childViews": [
{

63
src/levels/remote/remoteBranches.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "Remote Branches",
"zh_TW": "remote branch （遠端分支）",
"es_AR": "Ramas remotas",
"pt_BR": "Ramos remotos",
"de_DE": "Branches auf entfernten Servern",
"ja" : "リモートのブランチ",
"fr_FR": "Les branches distantes"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "注意顺序 -- 先在 master 上 commit!",
"zh_TW": "注意順序的問題喔！先在 master branch 上面送 commit",
"es_AR": "Prestá atención al orden: ¡commiteá sobre master primero!",
"pt_BR": "Preste atenção na ordem: commite no master primeiro!",
"de_DE": "Beachte die Sortierung -- committe zuerst auf dem master!",
"ja" : "順番に注意 -- まずmasterに対してcommitしましょう",
"fr_FR": "Prêtez attention à l'ordre -- les commits sur master d'abord !"
@ -204,6 +206,67 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Ramos Remotos no Git",
"",
"Agora que vimos o `git clone` em ação, vamos estudar aquilo que realmente mudou.",
"",
"A primeira coisa que você pode ter percebido é que um novo ramo chamado `o/master` aparece no nosso repositório local. Esse tipo de ramo é chamado de ramo _remoto_; ramos remotos possuem propriedades especiais pois eles servem a um propósito único.",
"",
"Ramos remotos refletem o _estado_ de repositórios remotos (desde a última vez na qual você falou com eles). Eles ajudam a entender as diferenças entre o trabalho local e o trabalho atualmente público -- um passo crítico a ser dado antes de compartilhar seu trabalho com os outros.",
"",
"Ramos remotos possuem a propriedade especial de, ao sofrerem um checkout, colocarem o repositório em modo \"Detached HEAD\". O Git faz isso de propósito, porque você não pode trabalhar nesses ramos diretamente; você é obrigado a trabalhar em outro lugar e só então compartilhar seu trabalho com o remoto (depois disso, os ramos remotos serão atualizados)."
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### O que é `o/`?",
"",
"Você pode estar se perguntando o que o `o/` no início do nome dos ramos remotos significa. Bem, ramos remotos possuem uma convenção obrigatória de nomes -- eles são mostrados no seguinte formato:",
"",
"* `<nome do repositório remoto>/<nome do ramo>`",
"",
"Então, se o ramo remoto é chamado `o/master`, o nome do ramo é `master` e o nome do repositório remoto é `o`.",
"",
"A maioria dos desenvolvedores na verdade chama o repositório remoto principal de `origin`, e não de `o`. Isso é tão comum que o Git define por padrão o nome `origin` para o repositório remoto quando você usa o comando `git clone` para clonar um repositório.",
"",
"Infelizmente o nome completo `origin` não cabe na nossa tela, então usamos `o` como uma abreviação :( Apenas lembre-se que no Git de verdade, o repositório remoto provavelmente será chamado `origin` em vez de `o`!",
"",
"É muita informação de uma só vez, então vamos dar uma pausa e ver um pouco de ação."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vamos fazer checkout de um ramo remoto e ver o que acontece"
],
"afterMarkdowns": [
"Como você pode ver, o Git nos colocou no modo \"Detached HEAD\", e não atualizou o `o/master` quando adicionamos um novo commit. Isso é porque o `o/master` só será atualizado quando o repositório remoto for atualizado."
],
"command": "git checkout o/master; git commit",
"beforeCommand": "git clone"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Para completar este nível, commite uma vez em `master`, e outra vez depois de fazer checkout em `o/master`. Isso vai ajudá-lo a sentir como os ramos remotos se comportam de forma diferente, e como eles apenas se atualizam para refletir o estado do repositório remoto."
]
}
}
]
},
"zh_TW": {
"childViews": [
{

55
src/levels/remote/sourceNothing.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "没有 source",
"zh_TW": "沒有 source",
"es_AR": "Origen de nada",
"pt_BR": "Origem vazia",
"de_DE": "Die Quelle des Nichts",
"ja" : "無のsource",
"fr_FR": "Source de rien du tout"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "本节的 branch 命令被禁用了, 你只能使用 fetch! ",
"zh_TW": "在本關卡中，不允許使用 branch 指令，因此你只能使用 fetch！",
"es_AR": "El comando branch está deshabilitado para este nivel, así que ¡vas a tener que usar fetch!",
"pt_BR": "O comando branch está desabilitado para este nível, então você terá de usar o fetch!",
"de_DE": "Der branch Befehl ist für diesen Level inaktiv, du musst also fetch benutzen",
"ja" : "このレベルではbranchコマンドが無効になっているのでfetchを使うしかない！",
"fr_FR": "La commande branch est désactivée pour ce niveau, vous devrez donc utiliser fetch !"
@ -180,6 +182,59 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### Coisas estranhas do `<origem>`",
"",
"O Git abusa do parâmetro `<origem>` de duas formas estranhas. Esses dois abusos vem do fato de que tecnicamente você pode especificar \"nada\" como uma `origem` válida tanto para o git push como para o git fetch. A forma como você especifica \"nada\" é por meio de um argumento vazio:",
"",
"* `git push origin :side`",
"* `git fetch origin :bugFix`",
"",
"Vejamos o que esses comandos fazem..."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"O que fazer push de \"coisa nenhuma\" para um ramo remoto significa? Deletar o ramo!"
],
"afterMarkdowns": [
"Aqui, excluímos com sucesso o ramo `foo` do repositório remoto por meio de um push de \"coisa nenhuma\" direcionado a ele. Até que faz sentido..."
],
"command": "git push origin :foo",
"beforeCommand": "git clone; git push origin master:foo"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Finalmente, fazer um fetch de \"coisa nenhuma\" para uma referência local cria um novo ramo"
],
"afterMarkdowns": [
"Bastante estranho / bizarro, mas de qualquer forma. É assim que o Git é!"
],
"command": "git fetch origin :bar",
"beforeCommand": "git clone"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Este é um nível rápido de resolver -- basta remover um ramo remoto com `git push` e criar um novo ramo local com `git fetch` para terminar!"
]
}
}
]
},
"zh_TW": {
"childViews": [
{

120
src/levels/remote/tracking.js
View file

@ -7,6 +7,7 @@ exports.level = {
"zh_CN": "Remote Tracking",
"zh_TW": "remote tracking",
"es_AR": "Trackeando remotos",
"pt_BR": "Seguindo remotos",
"de_DE": "Remote Tracking",
"ja" : "リモートのトラッキング",
"fr_FR": "Suivi de branche distante"
@ -16,6 +17,7 @@ exports.level = {
"zh_CN": "记住，有两种设置 remote tracking 的方法!",
"zh_TW": " 記住喔，有兩個方式可以去設定 remote tracking",
"es_AR": "¡Acordate de que hay dos formas de trackear un remoto!",
"pt_BR": "Lembre-se que há duas formas de seguir um ramo remoto!",
"de_DE": "Nicht vergessen, es gibt zwei Arten Remote Tracking einzurichten!",
"ja" : "リモートトラッキングを設定する方法が二つあるのをお忘れなく!",
"fr_FR": "Rappelez-vous qu'il existe deux façons de configurer le suivi de branche distante !"
@ -377,6 +379,124 @@ exports.level = {
}
]
},
"pt_BR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### Seguindo ramos remotos",
"",
"Uma coisa que pode ter parecido \"mágica\" nas lições passadas é que o Git sabia que o ramo `master` estava relacionado com o `o/master`. Certamente esses ramos possuem nomes similares, e tem todo sentido lógico conectar o ramo `master` do lado remoto com o ramo `master` local, mas essa conexão é demonstrada claramente em dois cenários:",
"",
"* Durante uma operação de pull, os commits são baixados em `o/master` e então são *mergidos* no ramo `master`. O alvo do merge é determinado a partir dessa conexão.",
"* Durante uma operação de push, o trabalho do ramo `master` local é enviado para o ramo `master` remoto (que é representado localmente por `o/master`). O *destino* do push é determinado da conexão entre `master` e `o/master`.",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Remote tracking",
"",
"Resumindo a história, essa conexão entre `master` e `o/master` é explicada pela propriedade de \"remote tracking\" dos ramos. O ramo `master` é configurado para seguir o ramo `o/master` -- isso significa que existe um alvo implícito de merge e um destino implícito de push para o ramo `master`.",
"",
"Você pode estar se perguntando como essa propriedade foi configurada no ramo `master` se você não executou nenhum comando ordenando que isso fosse feito. Bem, quando você clona um repositório com o Git, essa propriedade é configurada para você automaticamente. ",
"",
"Durante a clonagem, o Git cria um ramo remoto para cada ramo que existe no repositório remoto (ou seja, ramos como o `o/master`). Ele cria então um ramo local que segue o ramo atualmente ativo no repositório remoto, que geralmente é o `master`.",
"",
"Uma vez que a clonagem esteja completa, você terá apenas um único ramo local (para que você não seja sobrecarregado), mas você pode ver todos os ramos diferentes que existem no repositório remoto (caso você esteja curioso). É o melhor dos dois mundos!",
"",
"Isso também explica porque você vê a seguinte mensagem quando clona um repositório:",
"",
" local branch \"master\" set to track remote branch \"o/master\""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### Posso eu mesmo especificar isso?",
"",
"Sim, você pode! Você pode fazer com que qualquer ramo arbitrário siga o `o/master`, e se você fizer isso, esse ramo terá o mesmo destino de push implícito que e o mesmo alvo de merge que o `master`. Isso significa que você pode executar `git push` em um ramo chamado `realmenteNaoSouOMaster` e ainda assim ter seu trabalho enviado ao ramo `master` do repositório remoto!",
"",
"Há duas formas de configurar essa propriedade. A primeira consiste em fazer checkout de um novo ramo usando o ramo remoto como especificação de referência. Executar",
"",
"`git checkout -b realmenteNaoSouOMaster o/master`",
"",
"Cria um novo ramo chamado `realmenteNaoSouOMaster` e o configura para seguir o `o/master`."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Já foi conversa o suficiente, vamos ver uma demonstração! Vamos fazer checkout de um novo ramo chamado `foo` e configurá-lo para seguir o `master` do repositório remoto."
],
"afterMarkdowns": [
"Como você pode ver, usamos o alvo implícito de merge do `o/master` para atualizar o ramo `foo`. Veja como o master local não sofreu atualização!!"
],
"command": "git checkout -b foo o/master; git pull",
"beforeCommand": "git clone; git fakeTeamwork"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Isso também se aplica ao git push"
],
"afterMarkdowns": [
"Boom. Nós enviamos nosso trabalho para o ramo remoto `master` ainda que nosso ramo local tivesse um nome completamente diferente"
],
"command": "git checkout -b foo o/master; git commit; git push",
"beforeCommand": "git clone"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"### Forma #2",
"",
"Outra maneira de configurar remote tracking em um ramo é utilizando `git branch -u`. Executando",
"",
"`git branch -u o/master foo`",
"",
"configuraremos o ramo local `foo` para seguir o `o/master`. Se `foo` for o que estiver atualmente em checkout, você pode inclusive omiti-lo:",
"",
"`git branch -u o/master`",
""
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Vejamos outra forma realmente rápida de configurar remote tracking..."
],
"afterMarkdowns": [
"O mesmo de antes, apenas um comando mais explícito. Doce!"
],
"command": "git branch -u o/master foo; git commit; git push",
"beforeCommand": "git clone; git checkout -b foo"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Ok! Para este nível, vamos fazer push no ramo remoto `master` *sem estar* em um checkout do `master` local. Vou deixar você descobrir o resto, já que isto é um curso avançado :P"
]
}
}
]
},
"zh_TW": {
"childViews": [
{