TFS, GitHub ou outros

[Hugao]

Boas.

Com a minha ida para um CET eu pensei em organizar melhor os meus projetos e ter os mesmos sincronizados com o meu PC e com o de casa.

Eu ando a ver serviços como o Team Foundation Service e o GitHub mas ando em duvida em qual usar.

Já usei ambos mas o GitHub nem foi muito por causa de apenas ter um projeto privado.

Eu uso o Visual Studio mas queria um serviço que fosse compatível com várias ferramentas de desenvolvimento e que tivesse a possibilidade de ter vários projetos privados.

Qual é o source code management que recomendam?

Obrigado

Edited October 10, 2013 at 03:40 PM by Hugao

[nelsonr]

Boas,

verifica se este tópico parecido ajuda:

https://www.portugal-a-programar.pt/topic/60743-c-em-rede/

[Hugao]

Boas,

verifica se este tópico parecido ajuda:

http://www.portugal-a-programar.pt/topic/60743-c-em-rede/

Sim é isso que eu estou à procura, um serviço tipo Team Foundation Service, GitHub e Bitbucket.

Eu gostava de saber qual é o que o pessoal recomenda.

[Flinger]

Eu uso o SVN. Não é novo, mas tem feito o serviço.

Tens pluggins para quase todas as IDE's, para o VS existe o ankhsvn, e para operações mais complexas tens o tortoise (integra no explorer).

Se não estou em erro, o servidor, vem de raiz com o Linux, mas para Windows uso o VisualSVN. Bastante simples de usar, e gratuito, sendo que a única desvantagem da versão gratuita é não permitir administração remota, e para operações mais complexas teres de usar a linha de comandos (importação e exportação de repositórios/branches). Mas dá para o gasto. Também tens vários serviços online, incluindo o googlecode, embore ache que o repositório fica público.

O pessoal que tenha mais experiência pode comparar com outros.

[Warrior]

Tanto git como svn são boas opções.

Se procuras um repositório SVN gratuito podes experimentar o assembla, já o usei para vários projectos e é bastante simples de configurar.

[pikax]

eu uso o mercurial, para fazer merge e' um mimo 🙂

[pwseo]

O bitbucket usa git e permite-te ter vários repos privados.

[Hugao]

Eu uso o SVN. Não é novo, mas tem feito o serviço.

Tens pluggins para quase todas as IDE's, para o VS existe o ankhsvn, e para operações mais complexas tens o tortoise (integra no explorer).

Se não estou em erro, o servidor, vem de raiz com o Linux, mas para Windows uso o VisualSVN. Bastante simples de usar, e gratuito, sendo que a única desvantagem da versão gratuita é não permitir administração remota, e para operações mais complexas teres de usar a linha de comandos (importação e exportação de repositórios/branches). Mas dá para o gasto. Também tens vários serviços online, incluindo o googlecode, embore ache que o repositório fica público.

O pessoal que tenha mais experiência pode comparar com outros.

Eu no sourceforge tenho usado o SVN para meter o código do projeto na página do mesmo. Uso o tortoise

Tanto git como svn são boas opções.

Se procuras um repositório SVN gratuito podes experimentar o assembla, já o usei para vários projectos e é bastante simples de configurar.

Pelo que eu percebi no site o assembla não tem restrições a nível de users num projeto. É mesmo assim?

E a nível de repos privados como é o assembla?

O bitbucket usa git e permite-te ter vários repos privados.

Eu ontem andei a ver sobre o Bitbucket e pareceu-me uma boa opção

[Flinger]

Também fiquei curioso, e resolvi fazer uma rápida reciclagem do que por aí anda.

O Assembla parece-me mais limitativo no que toca a projectos, já que apenas te permite 1 projecto privado e 3 utilizadores (gratuito). Depois tens os públicos, onde também não vi restrições.

O bitbucket parece-me engraçado, e, para uso pessoal, não desgostei das funcionalidades do Git. Tenho por aqui um par de projectos em ideia, se avançar com eles sou capaz de experimentar este serviço. Já fiquei com mais algumas dúvidas no uso do Git para uso empresarial (pelo menos na minha empresa 😄 ), pois parece-me um bocado sujeito à asneira dos utilizadores. Por outro lado, ter uma cópia em cada PC, parece-me um mecanismo de backup fantástico 😄 .

Eu no sourceforge tenho usado o SVN para meter o código do projeto na página do mesmo. Uso o tortoise

O tortoise é uma ferramenta fantástica, mas se tiver o projecto inteiro no servidor (incluindo os ficheiros de projecto), gosto mais de usar os plugins para as IDE's. Acho mais prático, até porque não me carrega logo à cabeça ficheiros desnecessários. Dito isto, o editor de diferenças do Mylyn para o Eclipse é uma bela borrada (pelo menos na versão que eu uso), por isso complemento sempre com o tortoise.

[Rui Carlos]

Pessoalmente passei do SVN para o Mercurial, e depois para o Git.

Hoje em dia o SVN não é uma opção que considere quando sou eu a escolher a ferramenta. Para as necessidades que tenho, o Mercurial é mais simples, e mais funcional.

O Git já me parece um pouco mais complexo, mas acabei por começar a usá-lo pela facilidade em alterar o histórico. O Git também me pareceu melhor ao nível de branch/merge (uso mais os branches com o Git, mas por vezes até me pergunto se a trabalho de gerir os branches realmente compensa).

No geral diria que quer o Git, quer o Mercurial são boas opções.

Relativamente a repositórios online, o Assembla parece-me um pouco limitado em termos de projectos privados. Acho o Bitbucket melhor opção.

Também tens a opção de colocares os repositórios numa máquina tua. Usando um sistema como o Git ou Mercurial, é muito fácil mais tarde colocares o repositório num outro local.

[Hugao]

Também fiquei curioso, e resolvi fazer uma rápida reciclagem do que por aí anda.

O Assembla parece-me mais limitativo no que toca a projectos, já que apenas te permite 1 projecto privado e 3 utilizadores (gratuito). Depois tens os públicos, onde também não vi restrições.

O bitbucket parece-me engraçado, e, para uso pessoal, não desgostei das funcionalidades do Git. Tenho por aqui um par de projectos em ideia, se avançar com eles sou capaz de experimentar este serviço. Já fiquei com mais algumas dúvidas no uso do Git para uso empresarial (pelo menos na minha empresa 😄 ), pois parece-me um bocado sujeito à asneira dos utilizadores. Por outro lado, ter uma cópia em cada PC, parece-me um mecanismo de backup fantástico 😄 .

Eu também achei o Assembla mais limitado nos projetos privado que é o que me interessa mais.

Eu já usei o git no Team Foundation Service para experimentar e até gostei, mas não explorei muito

O tortoise é uma ferramenta fantástica, mas se tiver o projecto inteiro no servidor (incluindo os ficheiros de projecto), gosto mais de usar os plugins para as IDE's. Acho mais prático, até porque não me carrega logo à cabeça ficheiros desnecessários. Dito isto, o editor de diferenças do Mylyn para o Eclipse é uma bela borrada (pelo menos na versão que eu uso), por isso complemento sempre com o tortoise.

Na altura usei o SVN porque foi aquele com que entendi 😛 e o tortoise chegava porque era só para meter o código fonte na página dos projetos.

Pessoalmente passei do SVN para o Mercurial, e depois para o Git.

Hoje em dia o SVN não é uma opção que considere quando sou eu a escolher a ferramenta. Para as necessidades que tenho, o Mercurial é mais simples, e mais funcional.

O Git já me parece um pouco mais complexo, mas acabei por começar a usá-lo pela facilidade em alterar o histórico. O Git também me pareceu melhor ao nível de branch/merge (uso mais os branches com o Git, mas por vezes até me pergunto se a trabalho de gerir os branches realmente compensa).

No geral diria que quer o Git, quer o Mercurial são boas opções.

O Mercurial nunca usei. Os únicos que usei foi o SVN, git e TFS (os últimos só para experimentar) por isso não posso dizer muito sobre o Mercurial.

Quanto ao git quando o experimentei até que me cativou.

Relativamente a repositórios online, o Assembla parece-me um pouco limitado em termos de projectos privados. Acho o Bitbucket melhor opção.

Também tens a opção de colocares os repositórios numa máquina tua. Usando um sistema como o Git ou Mercurial, é muito fácil mais tarde colocares o repositório num outro local.

Também concordo com a tua opinião, para projetos privados o Bitbucket é melhor.

Eu sei mas eu quero online porque eu sou de Viseu mas estou a estudar em Lisboa e o PC de casa é o da família pelo que não convém muito ter um sistema desses a correr :s

[Hugao]

Olhem desculpem a pergunta um bocado estúpida mas veio-me esta dúvida. O Git é um repositório local, isso quer dizer que por exemplo eu tenho o código fonte no PC1 e para o PC2 obter o código o PC1 tem de estar ligado?

Eu fiquei na dúvida por causa do "local"

[Rui Carlos]

Olhem desculpem a pergunta um bocado estúpida mas veio-me esta dúvida. O Git é um repositório local, isso quer dizer que por exemplo eu tenho o código fonte no PC1 e para o PC2 obter o código o PC1 tem de estar ligado?

Eu fiquei na dúvida por causa do "local"

O Git não é local, é distribuído. Pode estar ao mesmo tempo em várias máquinas (incluindo nas tuas máquinas "locais"). Regra geral, copias o repositório do PC1 para um servidor (e.g. github), e depois copias o repositório do servidor para o PC2. Mas também podes copiar do PC1 para o PC2, e obviamente que nesse caso o PC1 tem que estar ligado.

[Hugao]

O Git não é local, é distribuído. Pode estar ao mesmo tempo em várias máquinas (incluindo nas tuas máquinas "locais"). Regra geral, copias o repositório do PC1 para um servidor (e.g. github), e depois copias o repositório do servidor para o PC2. Mas também podes copiar do PC1 para o PC2, e obviamente que nesse caso o PC1 tem que estar ligado.

Obrigado pelo esclarecimento 😉

[KTachyon]

Normalmente tens um repositório central (normalmente denominado de origin). A partir desse repositório vais ter clones. Nos clones serão efectuadas alterações distintas do projecto inicial que está no repositório central e gravam as suas alterações (commit) que representam estados de um projecto. Qualquer um desses estados representa um ponto de onde se pode iniciar um novo ramo (branch) onde serão feitas alterações que não irão afectar o ramo principal do projecto (normalmente, o master). Um dos clones pode submeter as alterações (commits) que fez ao repositório central (push) e receber as alterações feitas ao repositório central (pull). As alterações de vários clones sobre o mesmo estado também são ramos que no final podem ser fundidos no mesmo ramo inicial (merge) e que normalmente são feitos do lado do clone antes de serem submetidos ao servidor.

Um exemplo da utilidade dos branches:

Tens um projecto que tem já uma versão em produção (por exemplo, 1.0). Estás a trabalhar nas funcionalidades novas que vais introduzir na versão (por exemplo, 1.1), mas surge um problema (issue) na tua versão 1.0 que tem que ser resolvido rapidamente, o que te vai obrigar a lançar uma nova versão de correcção (por exemplo, 1.0.1).

O estado da tua versão 1.0 é o mesmo que o que tens no branch master. As novas funcionalidades que estás a implementar para a versão 1.1 estarão num outro branch (por exemplo, dev). A qualquer altura podes simplesmente mudar para o branch master (checkout), criar um novo branch (por exemplo, hot_fix) fazer as alterações que pretendes para resolver o problema, juntar (merge) com o master e voltar para o branch dev, juntar o master ao dev para voltares a garantir a consistência do dev e continuar a trabalhar na versão 1.1.

Tens outra funcionalidade que são as tags. No exemplo anterior, uma tag serviria para identificar o estado de cada uma das versões que colocares em produção. Dessa forma sabes que, se estás a suportar as versões 1.0.1 e 1.1, se ocorrer um bug na 1.0.1 que não ocorre na 1.1, sabes identificar facilmente qual é o estado do código para o binário que tem esse bug.

Durante o desenvolvimento em equipa, cada elemento vai ter um clone do repositório central, e esse repositório vai manter todo o código realizado pela equipa, e nos clones vão sendo feitas alterações ao projecto. É perfeitamente comum cada elemento estar a trabalhar numa funcionalidade diferente do projecto e ter, portanto, um branch distinto só para a funcionalidade que está a implementar. Esses novos branches podem ser submetidos para o repositório central (podendo manter a sua identidade) e fundidos com o branch de desenvolvimento. Isto pode causar conflitos se, nos dois branches houverem alterações nos mesmos ficheiros por diferentes elementos. Muitos desses conflitos são resolvidos pelo Git, mas existem conflitos que têm que ser resolvidos manualmente, normalmente com a ajuda de uma ferramenta que apresenta as diferenças entre versões (diff). Este tipo de conflitos só ocorre quando existem alterações na mesma parte dos ficheiros que não podem ser inferidas de forma lógica.

Para agilizar o desenvolvimento em equipa, é boa prática sejam feitos merges frequentes de funcionalidades (features) completas com o branch de desenvolvimento.

Finalmente, e mais importante (lol): SVN é lixo.

[Virneto]

Normalmente tens um repositório central...

(...)

(...)

...com o branch de desenvolvimento.

Muito bom este flash.

Referes aí vários aspetos/possibilidades do desenvolvimento de projetos em equipa que eu desconhecia!

Cheers 👍

Edited October 12, 2013 at 02:02 AM by Virneto

[Hugao]

Normalmente tens um repositório central (normalmente denominado de origin).

(...)

Para agilizar o desenvolvimento em equipa, é boa prática sejam feitos merges frequentes de funcionalidades (features) completas com o branch de desenvolvimento.

Muito obrigado pela informação 🙂 por acaso ia perguntar como o funcionam os commit e os branch 😛

Então deixa ver ser percebi. O código-fonte está no repo central e conforme a minha equipa vai fazendo alterações podemos integrar essas alterações no repo central com o push e receber as alterações dos outros membros com o pull.

Os branch são tipo categorias ao longo do desenvolvimento do projeto e podem ser juntos uns aos outros.

Mas eu ainda estou um bocado na dúvida na questão do ramo central (é o código-fonte principal??) e na questão do merge

[KTachyon]

No Git não existe o conceito de ramo principal. Todos os ramos são principais até o seu estado final ser fundido (merged) com outro ramo e esquecido. Mas podes sempre voltar a pegar nesse ramo e fazer mais alterações.

Podes mesmo criar um ramo do estado de um projecto que diverge do projecto inicial, tornando-se num outro projecto que tem por base um estado desse projecto inicial. Esse ramo pode ter sido colocado num clone do projecto inicial e que acaba por se tornar numa origin para outro projecto.

Edited October 12, 2013 at 08:16 PM by KTachyon

[Hugao]

No Git não existe o conceito de ramo principal. Todos os ramos são principais até o seu estado final ser fundido (merged) com outro ramo e esquecido. Mas podes sempre voltar a pegar nesse ramo e fazer mais alterações.

Podes mesmo criar um ramo do estado de um projecto que diverge do projecto inicial, tornando-se num outro projecto que tem por base um estado desse projecto inicial. Esse ramo pode ter sido colocado num clone do projecto inicial e que acaba por se tornar numa origin para outro projecto.

Acho que já percebi 😛 obrigadão 😁

E obrigado a todo aqueles que me ajudaram 😉

Edited October 12, 2013 at 08:35 PM by Hugao

[Hugao]

Bem já me estou a entender com isto 😉 mas só tenho aqui uma dúvida. Eu quando crio o repo e quando faço o commit ele cria o branch master, mas eu inicialmente cria ter dois branch, o stable e o dev.

Como é que eu faço para quando fizer o primeiro commit ele enviar para o branch dev?

Nota: Eu criei os branch pelo site do bitbucket