Oque é esse tal de git/github ?

[NetBoy16 72]

Pessoal, alguém pode me explicar oque seria git/github? eu sei que é controle de versao, ta, mas pra que serve, qual a vantagem, oque realmente é, talvez esteja sendo ironico e confuso(sendo que já falei que é controle de versao), mas ainda nao entendi direito sua funcionalidade, vantagens, etc...

 

alguém pd me explicar pf ?

[Evandro Oliveira 331]

Sessão errada.

 

http://forum.imasters.com.br/forum/293-metodologias-de-desenvolvimento/

 

o git eh um sistema de versionamento, pra criar versoes do seu software, imagina o seguinte, você criou 20 funcionalidades excelentes no seu software, e dae ao add +1 funcionalidade, o programa para, com o versionamento você pode voltar o codigo a tras, pra versao anterior, e ficar com as 20 funcionalidades q você sabe q funcionam corretamente....

 

o github eh um site q prove este servico, gratuita/monetariamente (depende da sua conta)....

[shini 318]

ter varias versão de um codigo fonte num repositorio distribuido, diferente do svn que é centralizado.

[NetBoy16 72]

o git eh um sistema de versionamento, pra criar versoes do seu software, imagina o seguinte, você criou 20 funcionalidades excelentes no seu software, e dae ao add +1 funcionalidade, o programa para, com o versionamento você pode voltar o codigo a tras, pra versao anterior, e ficar com as 20 funcionalidades q você sabe q funcionam corretamente....

 

o github eh um site q prove este servico, gratuita/monetariamente (depende da sua conta)....

 

vlw igor e evandro

 

mais uma coisa, vamos supor que eu e mais 2 amigos vamos fazer um sistema, eu vou cuidar da parte de gerenciamento de clientes, meu amigo do gerenciamento de usuarios e o meu outro amigo do gerenciamento de faturas por exemplo, tem como usar esse github? tipo, meu amigo terminou parcialmente/totalmente a parte dele, dai ele envia pro repositorio isso, depois que todos terminarem totalmente sua parte juntar todo o codigo fonte afin de montar o sistema, tem como? e então esse git seria um ctrl+z de emergência ?

[Bruno Augusto 417]

Se eu entendi direito como o GIT funciona, a resposta seria SIM.

 

Existiria um projeto principal o qual é composto de vários módulos. Criaria-se um Branch de desenvolvimento para não afetar aquilo que já se tem (se é que tem).

 

Então, cada um no seu GIT local faria um Fork do projeto e trabalharia, usando-se de outros Branches ou não.

 

Então, quando pronto, seria feito um Pull no GIT "oficial" do projeto com as modificações o qual será mesclado ou não a critério do Administrador.

[NetBoy16 72]

sim...

 

sim...

calma gente, sou novato ainda,kkk, qq eh fork, branch e todos esse outros termos ?

[Bruno Augusto 417]

De novo, se eu entendi direito, um Fork é, na tradução de Ramificação, um novo capítulo que o programador pode adicionar à história que do projeto.

 

No GIT Master tem os arquivos A e B. O programador cria um Fork localmente e cria o arquivo C.

 

Só GIT dele existe o C. Quando está tudo criado e testado certinho ele solicita (Push) ao administrador do GIT Master que este Fork, este capítulo, com a modificação que ele fez,seja integrado ao projeto.

 

Ainda no GIT local, cada novo Branch é um dos possíveis rumos que a história do Fork pode tomar.

 

É bem como o Igor disse no post #3. Você tem X funcionalidades no projeto e vai adicionar mais uma. Você cria um novo Branch de desenvolvimento para não tocar naquilo que já se tem.

 

Codifica, testa e se estiver tudo certo você mescla (Merge) no GIT Master, caso você seja o Administrador. Se você não for e/ou o GIT Master estiver online (GITHub, por exemplo), você faz um Push e o Administrador decide se aceita ou não, integrando ou não.

 

Pessoal, se eu estiver enganado me corrijam para eu aprender também :thumbsup:

[NetBoy16 72]

hmm, entao a parte do sistema de gerenciamento de usuarios que meu amigo fazer será o fork e caso eu queira adicionar mais uma funcao a essa parte isso seria um branch?

 

seria feito um Pull no GIT "oficial" do projeto com as modificações o qual será mesclado ou não a critério do Administrador.

 

oque seria fazer um pull ?

 

E caso eu utilize o github pra controle de versao do meu sistema, as outras pessoas tem acesso ao sistema/codigo ?

[Evandro Oliveira 331]

Precisamos primeiro separar quem é quem, pois isso interfere no método de trabalho.

Por questões de comoidade, daqui pra frente vou citar "controles de versão" e "sistemas de controle de versão" como VCS, que nada mais é que o acrônimo em inglês do segundo termo.

 

GIT é um VCS distribuído bla bla bla, acho que a parte da Wikipedia você já conhece, certo?

 

1. O que são e pra que servem as versões?

Sabe essas coisas de você baixar o Firefox 11 ou o Chrome 19? Basicamente, por trás do desenvolvimento, estão definindo marcos importantes na história daquele produto, são versões de um desenvolvimento. Uma mesma versão pode sofrer alterações significativas mas em quantidade insuficiente para caracterizar uma nova "Major Version", que é o número principal que vem depois do nome do Software. Nesse cenário, temos uma "Minor version". Uma Minor Version que figurou por muitíssimo tempo no cenário Web foi o Firefox 3.5.

 

Outras categorizações de versão incluem patch, que é um pacote de alterações normalmente voltado para correções de erros e falhas de segurança, build que é a contagem de "tentativas" de disponibilizar um software utilizável ou concluir uma tarefa de desenvolvimentot e revision que pode ser a busca minunciosa pelo código-fonte atrás de algo que você descobriu que pode ser uma falha ainda não explorada, por exemplo, ou a correção de uma regressão - bug corrigido que voltou.

 

2. Porque eu preciso salvar as minhas versões?

Podemos pegar como exemplo a última característica citada do tópico anterior: correção de regressão.

 

Uma vez que temos registrado onde o bug ocorreu e como ele foi corrigido, temos um importante ponto de partida que pode até mesmo resolver o nosso problema, talvez reaplicando a solução que foi sobrescrita por se achar não mais necessária. É possível retroceder em tudo que foi desenvolvido para realizar diversas análises - melhoria de código, de performance, de documentação - e até mesmo fazer comparativos de lógicas diferentes para confirmar se, realmente, o que estamos utilizando atualmente é melhor que uma solução que foi aplicada anteriormente.

 

Imagine, também, que lançamos uma nova versão de um software qualquer, que não teve boa aceitação da nova interface como, por exemplo, disposição dos botões, remoção de algum elemento ou a versão anterior era mais amigável para celulares e tablets. Novamente, podemos selecionar apenas estas características e aplicar à nossa versão atual.

 

3. Porque eu preciso de um sistema para controlar minhas versões?

Vários (vários mesmo) motivos, mas eu tenho um, muito simples, que vai convencer qualquer um que ler este post: Você não precisa ficar criando pastinhas 1.0, 2.0, 3.0... - com cópias completas do sistema - para cada vez que concluir um desenvolvimento. Fica tudo centralizado, no mesmo diretório, indexado de forma otimizada, compactada e documentada.

 

4. E pra desenvolver em equipe?

Quando falamos de trabalho em equipe, é importante que todos os envolvidos trabalhem sobre a mesma versão para evitar diversas dores de cabeça no momento da união dos códigos. VCS's ajudam, muito, também, nesta tarefa. A mescla é feita linha-a-linha - quando possível - modificando somente o que for novidade e mantendo um registro completo desta modificação, como quando aconteceu e quem fez.

VCS's impedem que ocorra o clássico problema de conflito, quando versionamos no sistema de arquivos, de a próxima atualização substituir arquivos novos por arquivos antigos que não foram trabalhados. Exemplo

 

NetBoy trabalha no arquivo 1.

Evandro trabalha no arquivo 2.

 

Evandro tem uma cópia completa do sistema e atualiza - via pastas (ftp, que seja).

Quando NetBoy terminar e enviar a cópia completa, estará enviando um arquivo B desatualizado, desfazendo o trabalho de Evandro.

 

Agora troque "no arquivo N" por "na linha N do arquivo A". O problema é um pouco mais delicado de se resolver. Um VCS trata tudo isso, fornecendo, inclusive, uma interface para tratamento de conflitos, quando um desenvolvedor tenta, a partir de uma versão desatualizada, alterar uma linha que já foi atualizada e não consta no repositório local.

 

5. O que são VCS's centralizados e distribuídos?

A diferença entre VCS's centralizados e distribuídos está na forma como você controla o repositório.

 

Para ter um VCS centralizado - CVS e Subversion, por exemplo - é necessário ter um servidor que atenderá as requisições de atualização. O repositório ficará amarrado àquele endereço de servidor e só será atualizado através do mesmo.

 

Já um VCS distribuído - GIT e Mercurial, por exemplo - leva uma cópia completa de si onde quer que seja despejado. Não é necessário estar online ou conectado a um servidor específico para adicionar uma nova versão ao sistema. Para atualizar sim, obviamente, mas qualquer espelho, sob qualquer endereço, pode servir de "atualizador" para o seu repositório. Até mesmo dois diretórios diferentes na sua máquina podem ser duas cópias do mesmo repositório onde uma atualiza a outra. É claro que isso não tem aplicação prática alguma.

 

6. E onde entra o GITHUB?

GITHUB se dispõe a ser mais um local onde há uma cópia completa do seu repositório, atuando como servidor centralizado de versões, mas sem essa real necessidade. Há, claro, a interface visual, a integração social, mas a grande sacada é estar disponível a qualquer hora e momento para um desenvolvedor que tenha acesso à Internet, sem a necessidade de configurar um servidor, abrir portas no firewall e ficar cuidando de DNS ou IP.

[NetBoy16 72]

Muito boa sua explicacao, deu pra entender bem mais, vlw :thumbsup:

 

mas e quanto as minhas 2 ultimas perguntas(a primeira ja foi respondida com esse pequeno artigo)?

[Prog 183]

:pinch:

http://lmgtfy.com/?q=controle+de+vers%C3%A3o+versionamento

[NetBoy16 72]

:pinch:

http://lmgtfy.com/?q=controle+de+vers%C3%A3o+versionamento

 

kkk, mas ai n vale neh, se eu quisesse saber oque a wikipedia tem a me dizer ja teria pesquisado :grin: lá é muito tecnico as explicacoes, por isso pergunto aki, alguem pode me responder pf ?

[Prog 183]

você precisa de um exemplo mais didático?

 

 

http://www.submarino.com.br/produto/1/218669

[Evandro Oliveira 331]

Pull/Push é o sistema de atualização do GIT. A tradução literal é Puxar/Empurrar, respectivamente.

 

De forma auto-explicativa, pull obtém as últimas atualizações, enquanto push envia suas modificações de/para um repositório remoto (no caso o GITHUB).

 

Se as outras pessoas tem acesso fica a seu critério. O plano gratuito do GITHUB fornece apenas repositórios abertos. Se precisar criar um repositório privado será necessário adquirir um plano pago.

[NetBoy16 72]

você precisa de um exemplo mais didático?

 

 

http://www.submarino.com.br/produto/1/218669

 

naaaoooo, eu preciso de uma explicação básica nao muito tecnica :pinch:

 

Pull/Push é o sistema de atualização do GIT. A tradução literal é Puxar/Empurrar, respectivamente.

 

De forma auto-explicativa, pull obtém as últimas atualizações, enquanto push envia suas modificações de/para um repositório remoto (no caso o GITHUB).

 

Se as outras pessoas tem acesso fica a seu critério. O plano gratuito do GITHUB fornece apenas repositórios abertos. Se precisar criar um repositório privado será necessário adquirir um plano pago.

 

 

vlw evandro :thumbsup: