Fazer vários commits ou dar um grande commit?

[Detonador PHP 1]

Pessoal, estou com uma dúvida em relação ao Github.

Ainda estou aprendendo a usar o Git e seus recursos e estes dias me deparei com uma dúvida.

 

Tinhas várias alterações para fazer no sistema em áreas diferentes e no final ao invés de dar um commit -all eu fui adicionando cada grupo de arquivos e dando os commits referentes a cada correção.

 

Por exemplo:

 

- git add index.php

- git commit -m "Instalei o monitoramento do analytics"

 

- git add contato_envia.php

- git commit -m "alterei o email do responsável pelo form"

 

- git add images/

- git commit -m "novas imagens da tela de cadastro"

 

E depois subi tudo para o github.

Só que gostaria de saber se fiz certo.

Esta é uma boa prática? Vocês tem ideias diferentes para dar commits em alteações de diferentes escopos no projeto?

 

Abraços!

[Enrico Pereira 299]

Sim, pequenos commits sempre! é tenso pegar um commit gigantesco e tentar entender.

[Detonador PHP 1]

Esta técnica está certa de dar add apenas nos arquivos alterados e dar commit?
Estou no caminho certo então?

[Enrico Pereira 299]

Um commit -> uma ação feita.

 

Você criou um formulário -> add e commit

Você mudou o nome de compradores para clientes -> add e commit

...

 

Veja se esse artigo dá uma clareada: http://bit.ly/NvKGpu

[Detonador PHP 1]

Muito boa matéria Enrico, com certeza vou baixar alguns projetos do Github para ver como eles tratam os commits.

Só mais uma pergunta:

 

Quando você está fazendo um projeto do zero, quando devo dar meu primeiro commit?

Depois do projeto já ter sido iniciado e os Htmls e os PHPs já estarem prontos? Assim os commits são de manutenção?

 

Ou damos commit já nas primeiras etapas do projeto, onde cada commit é dado após finalizar um arquivo, possa ser ele Html, CSS, PHP ou JS?

[Detonador PHP 1]

Estou com uma outra dúvida grandíssima, mas não sei se crio outro post.
Qualquer coisa o administrador me avisa que eu crio um novo post só que esta dúvida.

 

Seguinte:
O Git cada um tem uma cópia local do projeto, correto?

Dai você da os commits e se tiver conflito, agente corrige eles e termina com os push;

 

Mas e se tiverem pessoas acessando um repositório central?

Várias pessoas trabalhando na mesma máquina, por exemplo, um servidor local de arquivos, como ficaria o trabalho do Git? A mesma coisa?

 

Fico pensando:

Eu vou lá, altero o funcoes.js, dou Git status, git add funcoes.js e git commit.

Mas e se meu colega fizer a mesma coisa, quando ele der Git status vai acusar que o funcoes.js foi alterado e precisa ser rastreado, não?

 

Agora fiquei um pouco confuso.

[Henrique Barcelos 290]

Quando você está fazendo um projeto do zero, quando devo dar meu primeiro commit?

 

Depois do projeto já ter sido iniciado e os Htmls e os PHPs já estarem prontos? Assim os commits são de manutenção?

 

Ou damos commit já nas primeiras etapas do projeto, onde cada commit é dado após finalizar um arquivo, possa ser ele Html, CSS, PHP ou JS?

O primeiro commit é feito assim que você cria os primeiros arquivos, seja de configuração, seja de qualquer coisa. A cada alteração SIGNIFICANTE, você faz um commit.

 

Seguinte:

O Git cada um tem uma cópia local do projeto, correto?

 

Dai você da os commits e se tiver conflito, agente corrige eles e termina com os push;

 

 

 

Mas e se tiverem pessoas acessando um repositório central?

 

Várias pessoas trabalhando na mesma máquina, por exemplo, um servidor local de arquivos, como ficaria o trabalho do Git? A mesma coisa?

 

 

 

Fico pensando:

 

Eu vou lá, altero o funcoes.js, dou Git status, git add funcoes.js e git commit.

 

Mas e se meu colega fizer a mesma coisa, quando ele der Git status vai acusar que o funcoes.js foi alterado e precisa ser rastreado, não?

Se você faz as alterações primeiro, seu colega não conseguirá fazer o push, será obrigado a fazer um merge, resolvendo os possíveis conflitos.

[Bruno Augusto 417]

Eu não sou assim um guru do GIT, mas eu não faço pequenos commits assim não. Eu pego uma idéia que eu tenho elaborada, se eu ver que vai influenciar outras áreas do código eu crio um branch novo, codifico e só então faço o commit.

[Enrico Pereira 299]

Só para lembrar: o GIT não é específico para programação, não tem nenhuma relação com nenhuma linguagem, ele trabalha simplesmente com arquivos, de qualquer tipo. Serve tanto para escrever um livro quanto para criar uma aplicação.

 

O comum em um projeto em equipe é dar um git pull antes do push e ter branches separados.

 

O primeiro commit é geralmente o "Initial commit", é tão comum quanto o episódio Piloto em seriados :lol:. Esse commit geralmente engloba o README, e coisas bem básicas como estrutura de diretórios, pequenas configurações, .gitignore, etc. A intenção de usar um controle de versão é controlar as versões (como o próprio nome diz), logo você não deve fazer todo o projeto e dar um commit do tipo "Fiz muita coisa, vê aí bródi! mó dahora os bagui!!1!".

[JCMais 75]

Referente à questão de como efetuar os commits, e de uns tempos para cá estou usando essa técnica: http://nvie.com/posts/a-successful-git-branching-model, ainda estou vendo como ela se sai, mas estou gostando da organização que proporciona.

[Detonador PHP 1]

Entendi a questão dos commits. Sempre que eu fizer uma alteração significativa faço um commit. Evitar commits de grande escala pois é difícil de manter as versões desta forma.

 

Só ainda ficou uma dúvida que é a questão dos arquivos "compartilhados".

Pelo que entendi do GIT, ele verifica em sua máquina se houve alteração em seus arquivos. Então quando da o git status ele informa quais arquivos foram alterados.

 

Mas se mais de uma pessoa estiver usando os arquivos da mesma máquina? Onde trabalho, todos nós usamos um servidor local de arquivos, ou seja, uma máquina que serve apenas para deixar nossos arquivos centralizados.

 

Então pela rede, agente acessa estes arquivos e faz o FTP.

 

Pergunto:

Se configurarmos o GIT pra verificar esta máquina, sempre que alguém fizer alteração nos arquivos, o git status vai acusar que tem alteração, isso na teoria iria complicar o trabalho, pois imagine como seriam os commits.

 

Porque eu teria que dar commit apenas nas minhas alterações, mas se o git status pegar as alterações de todos os arquivos, mesmo não sendo eu que os alterei, não poderia fazer estes commits.

 

Não sei se consegui deixar claro.

Qualquer coisa eu dou um exemplo mais prático.

 

Abraços!

[Enrico Pereira 299]

FTP?

 

 

Porque não trabalha com GIT direto? é como você ter uma Ferrari e querer usar um Fusca velho. Faça o deploy com GIT, esqueça o FTP!

 

:seta: http://blog.thiagobelem.net/automatizando-a-instalacao-deploy-e-atualizacao-de-sites-com-git/

 

O git status é na sua máquina local, poderia reformular um pouco sua pergunta? está confuso, você está misturando máquina local com servidor e com FTP, está impossível de entender o real objetivo da pergunta.

[Detonador PHP 1]

Nós temos em rede 11 computadores.

- 4 para desenvolvimento

- 1 para design

- 1 para financeiro

- 4 para comercial

- 1 para armazenar arquivos dos projetos

 

E os 4 desenvolvedores trabalham só nesta máquina, ou seja:

Eu configurei meu Sublime pra acessar os arquivos desta máquina

O outro desenvolvedor tb configurou o sublime dele pra acessar os arquivos da mesma máquina.

 

Então quando eu modifico o app.css, eu modifiquei o arquivo que tava na rede.

Se por acaso outros desenvolvedores acessarem LOCALMENTE este arquivo, eles vão pegar ele atualizado, isso porque está CENTRALIZADO o trabalho com projetos.

 

Então pra deixar bem claro.

PC1 - Desenvolvedor 1
PC2 - Desenvolvedor 2

PC3 - Desenvolvedor 3

PC4 - Desenvolvedor 4

PCArquivos - Máquina que armazena arquivos

 

Então o PC1 modifica diretamente os arquivos do PCArquivos

PC2 modifica diretamente os arquivos do PCArquivos

PC3 modifica diretamente os arquivos do PCArquivos

PC4 modifica diretamente os arquivos do PCArquivos

 

Assim evitamos de publicar arquivos antigos.

 

A minha pergunta é:
Tem como trabalhar com git assim?
Ou seria melhor que cada máquina de um desenvolvedor tivesse sua própria versão do projeto?

[Enrico Pereira 299]

Você precisa colocar na sua mente uma coisa: GIT é distribuído. Esqueça os outros tipos de sistemas centralizados, vamos focar em GIT. Obrigar a centralização do projeto é uma má prática.

 

Cada máquina obrigatoriamente precisa ter um clone do repositório central, e esses repositórios remotos podem enviar modificações para o servidor (através do git push) e os desenvolvedores podem atualizar seus repositórios baixando as atualizações da máquina (através do git pull).

 

Ou seja: se o desenvolvedor quer ter certeza de que a versão dele é a atualizada, basta ele rodar um git pull, que irá baixar as atualizações feitas no servidor que ele não possui e realizará o merge, fazendo tudo ficar atualizado perfeitamente.

 

Para que os computadores modifiquem o repositório central, você necessita de criar um servidor remoto de GIT (um tutorial: http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux), mas isso é complicado e eu particularmente não recomendo, minha dica é: compre uma contra premium no GitHub para armazenar os projetos, é mais prático, mais barato e em minha opinião mais seguro (lembre-se de que se essa máquina der tilt, já era).

 

Eu recomendo que você dê uma olhada nesse screencast: http://blip.tv/akitaonrails/screencast-come-ando-com-git-6074964. Apesar de longo (mais de 3 horas) possui um conteúdo valioso. Foi útil para meu aprendizado em GIT e provavelmente será para você.

 

HTH

[Detonador PHP 1]

Acho que agora sim responderam todas minhas dúvidas hehehe

Valew pessoal... vou dar uma olhada sim neste screencast

Abraço a todo!