[OFF-TOPIC] (webnário de) o que github?
Pessoal, Aproveitando o embalo sobre soluções (web livres) para facilitar a nossa vida em colaboração com outras pessoas, gostaria de anunciar que vai haver um webnário de GitHub amanhã também ( https://github.com/blog/906-github-training-tomorrow). Gostaria de pedir para quem conhece o GitHub (Benilton Carvalho, Fernando Mayer, ...) para dar uma pequena noção para a gente da ferramenta. Inclusive, pelo que andei lendo, é possível hospedar dados lá e importá-los por link, ótimo para CMRs. Parece ser útil para quem tá desenvolvendo dissertação/tese por ser gerenciador de versões, tô certo? Grato. Walmes. ========================================================================== Walmes Marques Zeviani LEG (Laboratório de Estatística e Geoinformação, 25.450418 S, 49.231759 W) Departamento de Estatística - Universidade Federal do Paraná fone: (+55) 41 3361 3573 VoIP: (3361 3600) 1053 1173 e-mail: walmes@ufpr.br twitter: @walmeszeviani homepage: http://www.leg.ufpr.br/~walmes linux user number: 531218 ==========================================================================
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
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 <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.
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.
participantes (4)
-
Benilton Carvalho -
FHRB Toledo -
Leonard Assis -
Walmes Zeviani