Só completando: O conceito do GitHub é quase o mesmo de controle de versão como o svn, mas chega a ser bem mais que isso, acredito que uma comparação mais justa seria com um sourceforge da vida. Se é fácil ou complicado de mexer, vai do gosto de cada um. Eu quando começei a mexer com o GitHub achei meio chatinho no início, mas acabei acostumando. lmassis <at> yahoo <dot> com <dot> br assis.leonard <at> gmail <dot> com 2011/8/16 Benilton Carvalho <beniltoncarvalho@gmail.com>
Para entender o que o GitHub, e' necessario entender um pouco do conceito do 'git' (a explicacao abaixo nao contem codigo algum e trata-se apenas de uma exposicao de conceitos).
O git e' um software que oferece controle de versoes de arquivos. Como exemplo, tome o caso usual no qual voce esta' escrevendo um codigo que faz uma serie de manipulacoes em um banco de dados. A maioria dos usuarios salvara' esse arquivo usando nomes como "Manipula.R".
Acontece que ao fazer alguma modificacao no codigo de "Manipula.R", o usuario cuidadoso vai querer manter as duas versoes do codigo (a original e a modificada). Entao, ele acaba por salvar a versao modificada como "Manipula1.R". Se o usuario for um aluno escrevendo tese, chega-se facilmente a "Manipula20.R".
Usando o 'git', manter essas diferentes versoes nao e' tarefa tao complexa quanto lembrar-se o que cada uma das 20 versoes diferentes tem.
Tudo comeca por fazer analogia a uma arvore: seu codigo original e' o tronco (master); cada modificacao em progresso e' um galho (branch).
Partindo do Manipula.R, voce observa que precisa fazer modificacoes. Neste ponto, voce cria um novo branch (existe um comando para isso que, em teoria, copia o "Manipula.R" para uma pasta escondida). Como sua arvore agora possui um novo galho, voce precisa informar ao 'git' onde vc vai trabalhar (no tronco - master; ou no galho - branch). Para as modificacoes, voce informa que vai trabalhar no branch.
Qualquer modificacao feita no branch nao afeta o tronco principal (master). Na pratica, isso quer dizer que se voce quiser executar a versao original do Manipula.R, basta mudar do branch para o master. A outra vantagem e' que, dada essa independencia dos galhos com o tronco principal, voce nao precisa criar arquivos Manipula1.R / Manipula2.R / etc.
Uma vez que voce esteja satisfeito com as modificacoes feitas no galho da sua arvore, voce incorpora (une) o galho ao tronco. Esse processo e' chamado 'merging' (existe um comando para isso). A parte legal e' que, mesmo depois do merge, voce pode retornar `a versao original do codigo e tudo isso sem vc ter q manter Manipula1/Manipula2/etc...
O outro conceito usado bastante e' em colaboracao de codigo. Suponha que o Walmes comecou com a versao original de 'Manipula.R', dai' o Paulo pegou carona e decidiu tentar uma modificacao dele proprio... Neste caso, o Paulo pode criar um branch dele e fazer as modificacoes ali. Uma vez que o Paulo fizer as modificacoes, ele pode submeter um pedido de merge ao tronco principal, que sera' (ou nao) aprovado pelo Walmes para incorporacao plena no codigo original.
E' possivel manter arquivos binarios sob 'git' tambem. Mas por motivos que fogem o escopo da mensagem, isso nao e' algo muito recomendado (para os interessados, manter diffs de arquivos binarios nao e' algo legal).
Outra aplicacao do conceito do git: vc esta' trabalhando num artigo com diversos autores... Cada autor pode criar um branch e trabalhar nesse branch... depois voces podem "merge" todos os branches para montar o artigo final...
Note que o git nao liga se o arquivo e' um script em R, um programa em C, um documento em TXT ou TeX. O importante (no meu ponto de vista) e' que seja um arquivo texto padrao (ie, nada de Word, PowerPoint, por exemplo). A outra coisa importante e' que o git nao exige a existencia de um servidor, voce pode fazer tudo isso num diretorio qualquer do seu computador.
Pronto, dito isso (em suma, o git transforma sua linha de producao num esquema que usa uma arvore como modelo; no qual a parte estavel eh o tronco e as modificacoes em curso sao os galhos), fica menos enrolado entender o que eh o GitHub.
GitHub e' um portal no qual voce pode criar projetos (de codigo). Por exemplo, os pacotes que eu desenvolvo estao la'. Eu posso fazer todas essas coisas de branching, merging e reverting usando o website. Como ele e' um portal, o site funciona como um servidor. Assim, eu faco as modificacoes (criacao de galhos, unificacoes com tronco, etc) no meu computador e sincronizo com o servidor. Outros usuarios do website podem acompanhar o projeto.
Por exemplo, um dos meus colaboradores acompanha as modificacoes que tenho nos meus pacotes. Quando ele tem alguma sugestao, ele clona o meu projeto e faz as modificacoes ao gosto dele... Uma vez que as modificacoes estao prontas, ele (via website) manda as modificacoes para o meu projeto e eu, entao, preciso aprovar ou nao... Se aprovadas, as mudancas dele (antes independentes do meu projeto) sao incorporadas ao tronco principal.
Para facilitar acompanhamento de projetos, o GitHub oferece a possibilidade de voce "seguir" outras pessoas, incorporando tambem uma parte 'social' ao projeto.
Em termos de gerenciamento de projeto, GitHub tambem oferece servicos de Wiki e Bug Tracker.
Todos esses servicos sao gratuitos, na condicao de que o seu projeto seja publico.
Se voce nao quiser que outros usuarios vejam o seu projeto, voce pode criar projetos privados... mas apenas se voce for um usuario pago.
b _______________________________________________ R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.