Bela explicação Benilton... Me interesso, vou ver esse webnário e ver se aprendo mais alguma coisa!
A propósito acho uma boa também citar o org-mode do emacs... Ele é uma interfaceplain do emacs para gerenciar projetos e outros tipos de coisas "agendáveis"! Não sou um usuário afinco dele mas acho legal citar p/ o público em geral que talvés encontre utilidades MAIORES para o buffer! abraço, FH 2011/8/16 Benilton Carvalho <[email protected]> > 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 > [email protected] > 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. >
_______________________________________________ R-br mailing list [email protected] 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.
