Git para quem vem de SVN

[Hugo Ferreira]

Boa tarde,

Alguém que já trabalhou com SVN e que tenha mudado para Git ?

Após avaliar o Git, encontrei uma falha que me impossibilita de avançar.

Eu vejo um produto como o todo e não apenas o motor.

Com SVN, qualquer cliente básico, consegue mostrar as pastas e ficheiros em árvore, para que eu possa selecionar determinada nó e ver o log de alterações. Também consigo ver em árvore o que está alterado para commit.

Isto é um dado adquirido com qualquer cliente de SVN (se não tiver isto, para mim não passa de uma versão alpha).

Estas 2 simples funcionalidades não consigo encontrar em nenhum cliente Git para macOS (aliás acho que não encontrei em nenhum no geral).

Sei que isto não tem haver com o motor porque o Git em linha de comandos suporta.

Ou eu é que ainda não cheguei lá porque o Git é diferente do SVN (apesar de serem 2 ferramenras com o mesmo propósito) ou realmente apesar do Git já ter mais de uma década, é muito pobre no que respeita a tooling.

[Ricardo Araújo]

Viva,

Eu passei de SVN para TFS e depois para GIT... tenho te a dizer que agora só consigo gostar de GIT. Em termos de ferramentas, utilizo o Git Extensions e não quero outra coisa :)  

Relativamente ao histórico das pastas:

-apesar de não me ser útil, acabei de testar e podes pedir o histórico no file tree duma pasta. Ele vai te dar todos os ficheiros lá dentro alterados e respectivo dif. Depois se quiseres ver o hitórico de cada um basta fazer duplo click.

--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos do Google.
Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie um email para riapt+unsubscribe@googlegroups.com.
Para publicar uma mensagem neste grupo, envie um email para ri...@googlegroups.com.
Visite este grupo em https://groups.google.com/group/riapt.
Para mais opções, visite https://groups.google.com/d/optout.

[APintex Gmail]

Olá Hugo, já viste o GitKraken?

Abraço

António Pinto

api...@gmail.com

--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos do Google.

Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie um email para riapt+un...@googlegroups.com.

[Hugo Ferreira]

Viva,

Li más reviews acerca do Git Extensions para ambientes fora de Windows, uma vez que requer Mono.

Sinceramente nunca tive de instalar qualquer ferramenta em macOS que necessita-se do Mono mas dado que a disponibilidade de GUI no Git é bastante pobre apesar do Git já estar cá há uns anos (comparando com SVN), vou fazer um teste.

Sim, é mesmo isso que necessito e já testei várias ferramentas que não têm isto.

Para mim não é um preciosismo, pois uso e abuso disso.

Aliás não vejo melhor razão para uma ferramenta destas, senão torna-se apenas num backup.

Obrigado pela sugestão, vou testar.

[Hugo Ferreira]

O GitKraken tem um aspeto profissional e chamou-me à atenção mas desvalorizei logo porque é subscrição.

No dia 25 de outubro de 2017 às 15:59, APintex Gmail <api...@gmail.com> escreveu:

Olá Hugo, já viste o GitKraken?

Abraço

António Pinto

api...@gmail.com

No dia 25/10/2017, às 14:54, Hugo Ferreira <hferre...@gmail.com> escreveu:

Boa tarde,

Alguém que já trabalhou com SVN e que tenha mudado para Git ?

Após avaliar o Git, encontrei uma falha que me impossibilita de avançar.

Eu vejo um produto como o todo e não apenas o motor.

Com SVN, qualquer cliente básico, consegue mostrar as pastas e ficheiros em árvore, para que eu possa selecionar determinada nó e ver o log de alterações. Também consigo ver em árvore o que está alterado para commit.

Isto é um dado adquirido com qualquer cliente de SVN (se não tiver isto, para mim não passa de uma versão alpha).

Estas 2 simples funcionalidades não consigo encontrar em nenhum cliente Git para macOS (aliás acho que não encontrei em nenhum no geral).

Sei que isto não tem haver com o motor porque o Git em linha de comandos suporta.

Ou eu é que ainda não cheguei lá porque o Git é diferente do SVN (apesar de serem 2 ferramenras com o mesmo propósito) ou realmente apesar do Git já ter mais de uma década, é muito pobre no que respeita a tooling.

--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos do Google.

Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie um email para riapt+unsubscribe@googlegroups.com.

Para publicar uma mensagem neste grupo, envie um email para ri...@googlegroups.com.
Visite este grupo em https://groups.google.com/group/riapt.
Para mais opções, visite https://groups.google.com/d/optout.

--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos do Google.

Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie um email para riapt+unsubscribe@googlegroups.com.

[Hugo Ferreira]

Apesar do Tower ser "feio" (algum importante para os utilizadores de macOS), foi um dos que não testei e pareceu-me ler algo relacionado com o que pretende.

Hoje vou testar.

[Ricardo Araújo]

tens o https://www.sourcetreeapp.com/ que tem suporte para mac 

[Pedro Pereira]

Sourcetree é muito bom...mas sinceramente nada como linha de comandos para mim é mt mais fácil para criar branch's e prs

[Hugo Ferreira]

Cheguei a instalar o sourcetree ontem à noite mas obriga a um registo (ainda assim fiz) e pareceu-me (pelo menos não vi como contornar nesta primeira abordagem) que só dava para ligar a alguns repositórios definidos (como o famoso github).

Eu vou querer usar isto com o meu próprio git server privado no meu NAS/Linux tal com tenho hoje em dia com o SVN.

Ainda assim liguei a um repositório para testar e pareceu-me que não tem a funcionalidade de procuro.

Sim, o Git parece ter tudo ou quase tudo via linha de comandos mas estou interessado num GUI que faça tudo o que preciso.

Hoje vou experimentar o Git Extensions que ainda não testei e também o trial do Tower que nas specs parece ser exactamente o que pretendo apesar da interface um pouco rudimentar (não é um pré-requisito).

[Ricardo Araújo]

sinceramente não percebo como é que alguém pode preferir linha de comandos para o GIT... às vezes a coisa torna-se tão complexa mesmo com ferramentas cuja intenção é facilitar... não quero sequer imaginar casos complicados com linha de comandos!!! 

mas ya, respeito... às vezes ligando o complicometro a vida fica com mais adrenalina! :p 

[Paulo Ferreira]

Eu só uso a linha de comandos... é uma questão de hábito. Para ser honesto até me parece mais simples. Mas também nunca precisei de nada muito elaborado.

Como já foi referido o sourcetree tem um bom UI.

[Hugo Ferreira]

Pessoa,

Tower é a resposta !

Acabei de instalar e é soberbo.

Tem tudo até dá para usar para SVN 

Parece ter o melhor dos 2 mundos.

[Ricardo Araújo]

Acredito que sim! Custa é "apenas" $79

[Hugo Ferreira]

Para um projeto free não faz qualquer sentido pagar-se nem $79, nem $1.

Subscrição como é o caso de uma ferramenta sugerida aqui com um bom aspeto mas nem testei, não faz sentido e não acredito no modelo.

Subscrição faz sentido sim para software "gratuíto" em que a empresa está a pagar é o serviço de dados e suporte como software de gestão por exemplo.

Para quem ganha dinheiro com software faz todo o sentido pagar-se por uma ferramenta destas, tal com um mecânico paga para ter as suas corretas ferramentas na sua oficina.

Atualmente mais de 50% do software do meu macOS é pago mas tem sido ao longo do tempo.

O software gratuíto para mim só faz sentido se servir o propósito comparado com versões comerciais.

Já optei por software free porque serve o seu propósito e até bate software comercial, sendo largamente utilizado e com boa prespetiva de continuidade (ex: DB Browser for SQLite).

Também vejo se é um "abandonware" ou fica aquem do software comercial, opto pelo comercial.

Por exemplo, quis ter um cliente de SQL Server no macOS e comprei Navicat for SQL Server que em comparação com todos os outros é muito mais caro mas não só está muito acima (o que é um requesito para uma ferramenta destas), como cerca de metade das funcionalidades bate a própria ferramenta oficial da Microsoft.

Antes de comprar derivado ao preço, testei muitas outras mas basicamente foi instalar e desinstalar, pois voltava sempre para o magment studio.

[João Fernandes]

Nós usamos git com sourcetree. Este para além de ter suporte para terminal para os aficionados do commandline, suporta também gitflow. Para equipas é sequer difícil justificar svn comparando Git. Se a questão é ver em árvore, faz clone e já ficas com o código em árvore no teu file system 😁 Git vai muito para além de um simples repositório de codigo.

[Hugo Ferreira]

O sourcetree parece ser o mais popular, seguido do tower.

Depois de ter instalado, apareceu-me apenas 2 opções (ou 3) de repositórios conhecidos e não vi nenhum opção de custom o que me custa a acreditar pelo que com certeza deverá existir mas não foi intuitivo para mim.

Uma vez feito o login num repositório público já com um teste, mostrou-se (pelo menos em macOS) uma ferramenta nada intuitiva num fundo vazio.

O Tower depois de instalado, mostra muitos repositórios (provavelmente todos até à data) + uma última opção de custom (complicar para quê ?).

Testei primeiro com o meu repositório de teste e foi muito fácil ligar-me ao mesmo e tudo parece familiar (se calhar estou viciado no SVN).

Eu esperava tudo o que o Git oferece que eu tinha lido nos últimos dias (ou seja os comandos em forma GUI) + explorador de pasta onde podia fazer show log de um ficheiro ou pasta mas foi muito mais longe do que isso criando nossas necessidades. Não só consigo visualizar o famoso fluxo do git como consigo visualizar a evolução das pastas em árvore ao longo do tempo.

A forma como foi estrutura esta ferramenta, nota-se que foi muito bem pensada. É intuitiva para iniciados no Git como eu mas também disponibiliza todas (ou uma grande parte) das ferramentas/opções do Git.

No meu ver, se eu tiver de sair do Git para a linha de comandos sem ser por opção minha, então a falha é da ferramenta.

O que vejo nas outras ferramentas é apenas um conjunto de opções muito limitadas + um botão de abrir a consola. Parecem ferramentas alfa incompletas.

A pior de todas foi a primeira que experimentei que foi o Github Desktop que vindo de onde vem, esperava muito, muito mais.

A ferramenta fica toda explorada em meia dúzia (e não estou a exagerar) de cliques.

Depois do teste muito bem sucedido com o GUI, fui instalar o Git (ai sim usando exclusivamente a linha de comandos) na máquina com Linux e o processo é muito semelhante ao que fiz há vários anos na mesma máquina com o SVN.

- atualizar a lista de packages

- instalar

- aceder à pasta que quero e fazer git init

- o Git cria um pasta de ficheiros abertos de configuração (tal e qual o SVN) mas muito, muito mais vasto em termos de opções (todas estas configurações estão presentes no Tower :))

Gostei de facto que a ligação é full path, permitindo ter as pastas do Git onde quiser e não obrigatoriamente sobre o mesmo nó principal (ao contrário do SVN) mas lá está, isto tem haver com a filosofia descentralizada do Git.

[Hugo Ferreira]

A propósito João, admira-me não utilizarem o TortoiseGit :)

No dia 26 de outubro de 2017 às 09:47, Hugo Ferreira <hferre...@gmail.com> escreveu:

O sourcetree parece ser o mais popular, seguido do tower.

Depois de ter instalado, apareceu-me apenas 2 opções (ou 3) de repositórios conhecidos e não vi nenhum opção de custom o que me custa a acreditar pelo que com certeza deverá existir mas não foi intuitivo para mim.

Uma vez feito o login num repositório público já com um teste, mostrou-se (pelo menos em macOS) uma ferramenta nada intuitiva num fundo vazio.

O Tower depois de instalado, mostra muitos repositórios (provavelmente todos até à data) + uma última opção de custom (complicar para quê ?).

Testei primeiro com o meu repositório de teste e foi muito fácil ligar-me ao mesmo e tudo parece familiar (se calhar estou viciado no SVN).

Eu esperava tudo o que o Git oferece que eu tinha lido nos últimos dias (ou seja os comandos em forma GUI) + explorador de pasta onde podia fazer show log de um ficheiro ou pasta mas foi muito mais longe do que isso criando nossas necessidades. Não só consigo visualizar o famoso fluxo do git como consigo visualizar a evolução das pastas em árvore ao longo do tempo.

A forma como foi estrutura esta ferramenta, nota-se que foi muito bem pensada. É intuitiva para iniciados no Git como eu mas também disponibiliza todas (ou uma grande parte) das ferramentas/opções do Git.

No meu ver, se eu tiver de sair do Git para a linha de comandos sem ser por opção minha, então a falha é da ferramenta.

O que vejo nas outras ferramentas é apenas um conjunto de opções muito limitadas + um botão de abrir a consola. Parecem ferramentas alfa incompletas.

A pior de todas foi a primeira que experimentei que foi o Github Desktop que vindo de onde vem, esperava muito, muito mais.

A ferramenta fica toda explorada em meia dúzia (e não estou a exagerar) de cliques.

Depois do teste muito bem sucedido com o GUI, fui instalar o Git (ai sim usando exclusivamente a linha de comandos) na máquina com Linux e o processo é muito semelhante ao que fiz há vários anos na mesma máquina com o SVN.

- atualizar a lista de packages

- instalar

- aceder à pasta que quero e fazer git init

- o Git cria um pasta de ficheiros abertos de configuração (tal e qual o SVN) mas muito, muito mais vasto em termos de opções (todas estas configurações estão presentes no Tower :))

Gostei de facto que a ligação é full path, permitindo ter as pastas do Git onde quiser e não obrigatoriamente sobre o mesmo nó principal (ao contrário do SVN) mas lá está, isto tem haver com a filosofia descentralizada do Git.

[Pedro Pereira]

Ricardo Araújo para mim é mais simples..nao vejo em momento algum a complicar com descreves mesmo em merges com múltiplos branch's com o UI fico mais baralhado do que a linha de comandos e para mim torna-se mais simples tlv pk estou mais habituado a linha de comandos que uma tool em particular.

Fora que que sair do meu local development e for usar outra máquina ou até mm SSH não tenho alternativa senão usar terminal.

Mas isso é como td depende quem use e o que faça no dia a dia e gosto pessoal.

[Hugo Ferreira]

Com a linha de comando fazes tudo.

O Git nasceu da linha de comandos e são comandos simples, com nomes fáceis de entender e como habitual a net está inundada dessa informação mas mesmo assim nem seria preciso tanto. A site oficial do Git está muito bem feito e é quanto baste. Alias foi a partir de lá que facilmente coloquei o Git a funcionar ontem à noite só com uma simples leitura.

No limite a ferramenta gráfica fará também tudo se implementar todos os comandos ou andará um passo atrás.

No meu caso não consigo idealizar sem a ferramenta gráfica.

Não se trata de uma questão de ser mais "bonito" que é :) nem de saber os comandos que são fáceis de memorizar.

Para mim trata-se de eficiência.

O SVN sempre me tratou bem. Utilizo há cerca de uma década.

Aprendi a evitar conflitos de código na maioria das vezes mas por vezes o SVN fica com lock e perde-se tempo a resolver a questão.

Apesar de o Git ser atualmente "lá mode" ou melhor já é nos últimos anos, para mim a grande vantagem é poder trabalhar offline e com log total.

Dúvido que a grande maioria das pessoas que argumentam sobre isto, alguma vez tenha utilizado mas no meu caso utilizo em cerca de 30 a 40% do tempo o que é muito, o que me obriga a ter cópias de código ou a fazer commits a selecionar ficheiros com alguns partilhados porque gosto de ter os commits em separado e não fazer do repositório um simples caixote.

Tenho uma dúvida para os experts do Git:

Se eu estiver offline e fazer n commits para o meu repositório local e outro utilizador fizer o mesmo, o primeiro vai enviar as alterações para o central (que não é bem central). O que acontece ao segundo em termos de conflito num commit intermédio ?

Parece-me inseguramente assustador.

[João Fernandes]

Hugo,

o segundo faz fetch localmente dos commits que entretanto chegaram ao repositório remoto, resolve qualquer conflito que possa ter surgido e volta a fazer commit (que tem o resolve) e push para o repositório.

O GIT tem várias vantagens relativamente ao SVN, como o caso das branches não serem réplicas totais do código, sendo o switch entre elas quase imediato e tendo custo quase nulo de espaço adicional. Podes criar a tua branch local e fazer todos os disparates que não vai influenciar em nada as branches de desenvolvimento e isto tudo sem nunca influenciar em anda o repositório central (ou repositórios).

Usamos GIT há sensivelmente 3 anos e aumentou a produtividade da equipa e diminuiu drasticamente os tempos de lançamento. Apesar do GIT não impor qualquer workflow de trabalho, optamos pelo GitFlow que permite de forma muito facilitada o desenvolvimento isolado de features que são somente integradas após aprovação.

João Fernandes

[Hugo Ferreira]

OK, segundo estou a entender, no segundo aparecem os conflitos e ele resolve localmente (tal e qual como no SVN) mas já tinha feito commit local de vários !

Imagina que o segundo fez o commit 1, 2 e 3 mas os conflitos estão no 1 no 2 mas com o 3 está tudo bem (que são outros ficheiros).

Resolve os conflitos como se fosse um replace do commit 1 e 2 e volta depois a tentar sincronizar com o central ?

A situação dos branchs ainda não sabia o que é mais um ponto positivo a adicionar.

Sempre me fez comichão ter de duplicar o código fisicamente, razão pela qual evitava.

[Pedro Pereira]

Isso é a ideia de ser descentralizado se o segundo vai fazer push e a hashtag n faz match ele recebe um warning que existem alterações e tem de fazer merge localmente resolver os conflitos localmente e após isso fazer commit. Desta forma o repo fica sp limpo isto tendo em conta que tá a fazer o merge é a resolver os conflitos tá a verificar se passa os testes e está td dentro de ordem. E apos isso pode fazer push.. isto vai contra o "commit and forget"

On 26 Oct 2017 11:08 am, "Hugo Ferreira" <hferre...@gmail.com> wrote:

OK, segundo estou a entender, no segundo aparecem os conflitos e ele resolve localmente (tal e qual como no SVN) mas já tinha feito commit local de vários !

Imagina que o segundo fez o commit 1, 2 e 3 mas os conflitos estão no 1 no 2 mas com o 3 está tudo bem (que são outros ficheiros).

Resolve os conflitos como se fosse um replace do commit 1 e 2 e volta depois a tentar sincronizar com o central ?

A situação dos branchs ainda não sabia o que é mais um ponto positivo a adicionar.

Sempre me fez comichão ter de duplicar o código fisicamente, razão pela qual evitava.

[Pedro Pereira]

Se isso acontecer vais ter um merge por fases...ou seja ao fazer merge vais ter de resolver commit por commit. Quando fizeres o resolve de cada um vai estar td resolvido..as tools abstraem isso um PC mas na linha de comandos é isso que acontece.

[Hugo Ferreira]

OK, obrigado.

[João Fernandes]

Pedro, suponho que seja o famoso fast forward certo? É verdade que os clientes acabam por nos tornar preguiçosos sobre o que acontece na realidade.

[Pedro Pereira]

Não sei exatamente mas existem várias formas de tornar mais simples uma por exemplo é fazer squash dos commits em apenas um...e depois fazer o resolve desse único commit. Mas as tools abstraem um PC disso.. na linha de comandos normalmente faço sp rebase do que está no server c os meus commits e aí eu resolvo os commits..

[João Fernandes]

No meu caso, prefiro não fazer squash pois acabas por perder o histórico dos diversos commits, o que eu, pessoalmente, acho útil principalmente se por exemplo, possa precisar de fazer um cherry pick para uma branch onde a mesma alteração possa ser necessária sem ter de levar com tudo atrás.

Já agora, dos que aqui usam GIT, quais os repositórios que usam? 

2017-10-26 14:23 GMT+01:00 Pedro Pereira <cyberaf...@gmail.com>:

Não sei exatamente mas existem várias formas de tornar mais simples uma por exemplo é fazer squash dos commits em apenas um...e depois fazer o resolve desse único commit. Mas as tools abstraem um PC disso.. na linha de comandos normalmente faço sp rebase do que está no server c os meus commits e aí eu resolvo os commits..

--

João Fernandes

[Ricardo Araújo]

do lado do servidor usamos GitLab. Já tivemos antes GibBox mas a experiência foi muito má em termos de performance.

Relativamente à questão no ar:

quando tentamos fazer um push e já alguém colocou lá coisas há várias opções a seguir:

-Rebase -este rebase parece-me o vocês chamaram de squash (corrijam se estiver errado) - serve para que os teus commits sigam para o topo. Assim perdes a verdadeira história

-Merge - caso pretendas evidenciar a história dos acontecimentos usa o merge... os teus commits ficam representados cronologicamente no lugar certo e acaba por mostrar o teu caminho a convergir para o outro branch

-Force - apagas tudo o que os outros fizeram :) não é aconselhável. Só se usa em casos marados! 

tanto no merge como no rebbase o cherry pick é possível pois o número de commits continua igual, a história é que passa a ser contada de outra forma.

Normalmente faço o "rebase" manualmente com a ajuda do stash. Assim quando são coisas simples trabalho sempre no topo das alterações. 

[Hugo Ferreira]

Interessante.

Obrigado pela explicação.

No meu ver, também me parece mais lógica o rebase.

No dia 26 de outubro de 2017 às 17:59, Ricardo Araújo <ricardo...@gmail.com> escreveu:

do lado do servidor usamos GitLab. Já tivemos antes GibBox mas a experiência foi muito má em termos de performance.

Relativamente à questão no ar:

quando tentamos fazer um push e já alguém colocou lá coisas há várias opções a seguir:

-Rebase -este rebase parece-me o vocês chamaram de squash (corrijam se estiver errado) - serve para que os teus commits sigam para o topo. Assim perdes a verdadeira história

-Merge - caso pretendas evidenciar a história dos acontecimentos usa o merge... os teus commits ficam representados cronologicamente no lugar certo e acaba por mostrar o teu caminho a convergir para o outro branch

-Force - apagas tudo o que os outros fizeram :) não é aconselhável. Só se usa em casos marados! 

tanto no merge como no rebbase o cherry pick é possível pois o número de commits continua igual, a história é que passa a ser contada de outra forma.

Normalmente faço o "rebase" manualmente com a ajuda do stash. Assim quando são coisas simples trabalho sempre no topo das alterações. 

[Pedro Pereira]

Rebase n é squash..squash é fazer squash de tds os commits que tens para um...rebase é apenas meter os teus commits após os que estao no servidor. Obviamente se não fizeste push. Kk das formas isso n é alterar a verdadeira história.. até pk a verdadeira "história" é os commits que já estam feitos no servidor... Qual a lógica de ter um commit as 10h se só fizeste push as 12h e já existiam outros commits feitos que foram merge no servidor ?kk das formas ng faz commit directamente para master. Sim squash podes perder o histórico dos commits que estavam pendentes mas isso só dei como exemplo no caso de num merge em vez de fazer merge por fases fazer num único commit...o rebase resolve apenas uma parte mas continuas a ter de fazer resolve de cada um dos conflitos. Eu uso rebase no merge.. Acho que é bastante standard usar rebase.

[Ricardo Araújo]

Ok, já relembrei do squash. 

Discordo um pouco Pedro...

Posso estar a trabalhar numa Feature qualquer durante 1 mês e durante esse mês fazer commits locais e nunca fazer push. Depois quando terminar o desenvolvimento vou querer fazer push e vou querer manter o histórico... (o primeiro commit 1 mês atrás com o inicio das alterações... e por ai fora...) 

Neste caso só faz sentido o merge para manter a história graficamente e cronologicamente. 

o rebase neste caso estragava tudo

por outro lado, se eu apenas quero fazer um commit, normalmente faz sentido ir para cima para evitar criar duas entradas por commit. (commit e merge)

quando se trabalha numa equipa grande é preciso ter esse cuidado porque se não fica uma confusão. 

por exemplo, se uma equipa de 10, cada commit originar duas entradas (uma para o commit e outra para o merge) no fim de uns quantos commits aquilo fica dificil de interpretar.

exemplo simples: a linha vermelha parte do ultimo commit (azul) e a verde também... o gajo que fez o commit vermelho não tinha nada no servidor quando o colocou lá ... mas o gajo que fez commit verde optou por merge, então é obrigado a ter duas entradas, uma para o próprio commit e outra para o merge com o vermelho! 

quando este comportamento é multiplicado por muitos elementos da equipa depois quando se quer analisar ou perceber a razão de alguma coisa é mais complicado.

um exemplo disso:

[Hugo Ferreira]

Ontem à noite migrei um repositório SVN para Git e usei o --ignore-paths para excluir alguns binários que tinha anteriormente chegado à conclusão que não faziam sentido estar no repositório, conseguindo libertar mais de 1 GB !

Migração com sucesso, repositório extremamente mais compacto mas apesar de terem sido removidos os ficheiros a mais, ficaram as antigas entradas do SVN (revisions), o que fica feio.

Alguém já fez isto anteriormente limpando mesmo as entradas, ou seja, R1 > R2 > R3 em que na migração vai ficar R1 > R3 em vez de manter o caminho e só excluir o conteúdo ?

[Pedro Pereira]

Ricardo não havia necessidade de explicar isso td..tenho conhecimento disso. Eu só estou a dizer o que eu pessoalmente uso e sempre vi a maioria do pessoal fazer.... até pk nunca trabalhei c equipas de 10 pessoas num single projecto..e nunca fazemos commits por 1mes fazemos push depois... Fora que trabalhamos em termos de pr. Ou seja um branch Por feature..que acaba por ser mt mais simples de gerir e acabas por n ter nada disto..mas vamos imaginar que tamos a fazer dev directamente no master..com um equipa de 5 pessoas por norma fazemos commits e diários se fizermos commits por semanas quanto mais meses aí temos problemas bem maiores que um merge ou rebase..e aí o histórico nada vai valer....mas prontos são pontos de vista mas olha que trabalhei c muitas equipas em muitas empresas e a norma era rebase...o merge faz sim sentido se tiveres muitos commits sim..mas o normal são PCs commita diariamente sendo feitos push mas normalmente é só em branch's no final o merge tem de ser feito para o master e aí sim..é um merge e n rebase...

[Akira]

O que aconteceu ao keep it simple? No meu caso concreto, temos imensas pessoas a trabalhar no mesmo code base por isso apenas commits em próprio branch seguidos de merge para o master são permitidos. No máximo alguns cherry picks de último minuto pré release e siga. Rebase e outros são proibidos. Long running branches é pedir para dar merda no fim e são apenas permitidos se quem estiver a trabalhar nesses branches fizer pull ao master diariamente

[Pedro Pereira]

Os branch's nc devem ser long running small features.. um branch..keep it simple..rebase n é silver bullet cm disse anteriormente...vejam o conceito de pés do github e percebem o que quero dizer..projectos Open source são desenvolvidos por mta gente.

[Pedro Pereira]

PR desculpem...isto escrever a pressa no tlm da nisto

[João Fernandes]

Nós só usamos prs mas para a develop visto usarmos gitflow. Se for hotfix, PR para master e develop. Temos long running branches para as features grandes e cada Dev faz merge da develop (out master em caso de hotfix) para a sua branch sempre que ache conveniente. Cherry pick acontece aquando de uma base comum é precisa em duas features. Acaba por um desenvolver e passa os commits ao outro para que este faça cherry pick para a sua branch. 

Estamos há perto de 3 anos com este flow que tem funcionado muito bem, permitindo facilmente no Jenkins criar os builds do que seria o resultado final caso o pr fosse aprovado, portanto mesmo que o Dev não faça merge diariamente da develop (ou master) o build que vai para ser testado contém toda a develop mais os commits da branch em questão. 

[Pedro Pereira]

Deve ser interessante fazer os merges cm long running branch's mas aí está isso depende da empresa e da forma como gerem claro...nc me deparei c tal necessidade...trabalhei em grandes empresas mas equipas sempre foram pequenas..5 devs máximo e mm assim cm era em microservices e td modular nc havia assim grande necessidade de haver grandes merges ou mm long running branch's mas imagino que haja sítios assim.

[Pedro Pereira]

Kk das formas o que descreves João é mais ou menos o que temos nesta empresa para qual tou a fazer consultoria no entanto é raro haver long running branch's..a ideia é fazer pequenos incrementos do desenvolvimento e distribuir e n apenas desenvolver desenvolver e depois entregar..conceito de estar em Agile c entregas incrementais.

On 29 Oct 2017 7:45 am, "Pedro Pereira" <cyberaf...@gmail.com> wrote:

Deve ser interessante fazer os merges cm long running branch's mas aí está isso depende da empresa e da forma como gerem claro...nc me deparei c tal necessidade...trabalhei em grandes empresas mas equipas sempre foram pequenas..5 devs máximo e mm assim cm era em microservices e td modular nc havia assim grande necessidade de haver grandes merges ou mm long running branch's mas imagino que haja sítios assim.

[Hugo Ferreira]

Boa tarde,

Já consegui migrar os meus projetos de SVN para Git com histórico.

Cheguei à conclusão que o melhor não é só consola ou UI mas a combinação de ambos (pelo menos para uma fase inicial) !

O Git é muito parametrizável e deixa-me fazer tudo o que nunca pude fazer com SVN porque era dado como normal ser assim.

A criação de um repositório no SVN requer apenas 1 comando e VI num txt de utilizadores.

Depois o client SVN (UI) apenas faz checkout, commits e esquecer.

Fizemos um commit erradamente e fica para todo o sempre esse histórico.

A criação de repositórios no Git é tão parametrizável que permite moldar o Git exatamente aos meus requisitos em vez de ter de ser eu a alterar a forma de trabalhar.

Aproveitei a migração para remover toneladas de lixo que erradamente foi colocado no central ao longo do tempo (binários e coisas do género), libertando vários GB de informação, com muito cuidado para tudo ficar na sequência correta.

A velocidade de pesquisa é estupidamente rápida (instantânea) em todo o repositório.

Um dos repositórios que tenho com cerca de 2500 commits com o SVN tinha de consultar ranges de commits e demorava a passar para o próximo (pesquisar em todo o repositório nunca fazia).

À parte de poder trabalhar offline com controlo de revisões e super rapidez na pesquisa, existe um outro factor que acho muito importante e nunca vi mencionado: com o SVN para eliminar ficheiros, primeiro tinha de ir ao SVN eliminar, depois tenho de ir ao IDE retirar a referência e só depois commit e assim sem poder tirar o verdadeiro partido do refactoring. Aqui elimina-se o ficheiro no local correto que é nas pastas e o Git sabe detetar o que tem de ser marcado para ser eliminado pois devia e é a responsabilidade dele.