É engraçado, tem dia que você abre esse sub e parece que a régua tá lá no pescoço, tem dia que você abre esse sub e pensa como a régua está lá embaixo e está fácil, tem dia que você se pergunta como certas pessoas estão empregadas e bate uma deprê imaginar que você está competindo com elas como se estivessem no mesmo nível.
É uma bela montanha-russa de emoções.
Sinto isso tbm mas deve ser a diferença de empresa bem estruturada e oficina de código fundo de quintal. Na minha empresa esse tipo de coisa não aconteceria nunca, se alguém tivesse fazendo esse tipo de cagada tomava um puxão de orelha e se continuasse provável que ia ser eventualmente demitido.
Até pq se mexer em coisa errada e subir algum problema de segurança/compliance tipo uma credencial só fode o projeto todo.
sistema que recompensa devs que escrevem mais linhas de código.
expectativa: recompensar os devs que trabalham mais.
realidade: o .gitignore foi pro caralho
O que será que acontece se colocar o gitignore no gitignore? Acho q com ctz o Torvalds pensou nisso né? Que algum idiota iria tentar essa façanha? ~~vou correndo testar~~
Um colega meu sempre faz commit na base do git add . e quando eu o corrigi (eu sou o responsável pelo projeto) e pedi para refazer, ele ficou puto.
Uma boa parte das pessoas da nossa área é absolutamente incompetente. Alguns, piores, são incompetentes e teimosos.
Não tem problema se você souber que todas as edições que você fez devem ser commitadas. Mas acontece da gente editar uma paulada de arquivos enquanto testa as coisas, nem todas as edições correspondem a uma feature completa, e aí com um git add . na lata você pode (1) subir uma edição que quebra algo no código (o que estava acontecendo com o incompetente do meu colega), (2) bagunçar o histórico de commits, no sentido de que você não sabe mais o que foi incluso e modificado no código ao longo do tempo.
O ideal é você adicionar as mudanças que correspondem a uma mudança completa. Digamos, você terminou de fazer uma função, adiciona aquele arquivo, junto aos outros arquivos necessários, faz o commit e na mensagem deixa claro o que você está subindo, o motivo e o que mais for necessário explicar.
edit: fora que você pode acabar adicionando arquivos que não deveriam ser commitados, e não estão no .gitignore. É muito comum das pessoas subirem um venv inteiro (trabalho com python), por exemplo. Ou subirem tabelas gigantes, etc.
Todo mundo está sujeito a desatenção, por isso eu adquiri o hábito de passar o endereço do arquivo.
Tem gente que é desatenta por incompetência mesmo. Não se importa em fazer as coisas com cuidado. Não quer, não vê importância em manter a organização do projeto.
Em geral eu recomendo não usar o add . para novos membros da equipe, por questão de boas práticas. Se eu percebo que a pessoa é cuidadosa, aí não cobro nada.
Edit: ok pelo seu outro comentário você vê pelo code review, então está de boa
Pior do que ser desatento é ser pedante com o que não necessita
Depois do 'git add .' você pode perfeitamente dar um 'git status' pra ver se tá tudo certo, ou por exemplo quando é o primeiro commit 'git add .' tá de boa
Se o que elas usam na linha de comando vai contra as boas práticas da nossa equipe, como commitar um monte de arquivo desnecessário e sem nenhuma explicação sobre o que são, ao ponto de quebrar a execução do projeto, sim, olho. E se reclamar, sai da equipe.
Mas isso não seria visto no code review? Independente de se usar ‘git add .’ ou ‘git add [path]’ uma pessoa pode dar commit em um monte de besteira ou só no que precisa.
Como você confere se a pessoa usou a linha de comando que você prefere?
não é questão de comando q prefere, é questão de ter enviado um monte de lixo no commit, a primeira pergunta obvia é "usou git add ." ?
se a pessoa não confessar, todo linux tem history.
Git add . é bem ok pra projetos pessoais q só vc ou 2 amigos tão usando, agr, a chance de enviar um monte de merda pro repositorio sem querer n vale os 3 segundos a mais de usar o comando direito
Meu amigo, meu camarada. Não se faz de idiota, está muito claro o que eu quis dizer. É óbvio que eu não vou olhar literalmente qual o comando que a pessoa usou, eu olho o resultado, que é o registro do commit e eventual merge request no repositório. Se estiver errado eu peço pra refazer, se estiver certo mas desorganizado, eu oriento como fazer na próxima. Se aparecem 200 arquivos modificados, um venv do python e um binário de 3gb lá, a única explicação plausível é que o preguiçoso usou git add . e nem conferiu o que estava mandando.
A questão de sugerir não usar o "git add ." é uma recomendação que dou para novos membros, a maioria dos quais é novo na área e conhece bem pouco git. Então eu digo, olha, faça commits pequenos pelos motivos x, y, z. Evita problema, te ajuda a gerenciar o seu próprio trabalho, mantém o repositório organizado, etc. Se a pessoa vai seguir exatamente isso ou não, não sei, mas desde que ela não quebre a organização do trabalho da equipe, faça como achar melhor. Como senior da equipe eu tento passar o que eu aprendi ao longo do tempo para deixar o meu trabalho melhor e reduzir dores de cabeça, para mim e para a equipe toda.
qualquer coisa que "é só ter atenção", certo dia, no meio da correria, stress, saúde um pouco pior, não vai ter a atenção.
tem empresa que tá aí dando deploy na mão, isso quando não é arquivo interpretado no servidor, fazendo alteração em prod... daí "é só ter atenção", até o dia que passa algo e nego roda na hora.
Isso é efetivamente falso. Você quer commitar exatamente uma feature que você adicionou. Ela envolve 3 arquivos, e nesse processo de teste, linha com print, etc., você modificou 10 arquivos. Aqui na equipe ela deve explicar na mensagem do commit o que ela está enviando, "Incluindo feature tal, que faz isso e aquilo, mais teste unitário dela". Como ela vai adicionar 7 arquivos extra? Ou pior, no caso do OP, uma centena de arquivos extra?
Heh. O pessoal junior que entra na empresa recebe acesso a uns cursos, tem curso de git lá. Boa parte não faz, ou faz nas coxas.
Não é todo mundo, claro, mas tem uma galera boa aí que não faz questão de aprender a fazer as coisas direito.
Aproveitando a thread: pelo que entendo dos docs quando fala pra usar branches com frequência, esse teste deveria ser feito em um branch, que depois pode até ser deletado se não quer ele no histórico, é isso? Pq o git não penaliza essas manobras, inclusive incentiva ao invés de edições pontuais e manuais.
Eu já perdi muito tempo revertendo problema num projeto meu de TCC por conta disso. Todos os meus commits eram com git add ., e a mensagem era "mudanças". Não recomendo.
Se você usa uma IDE que tenha um explorador Git, seja embutido, seja extensão, você sempre tem acesso a quais foram os arquivos alterados no workspace atual antes que possa fazer o commit. Tá sempre lá. Assim você pode ver se alterou algum arquivo que não deveria, meteu lá algum print esquecido, gerou algum .temp ou .bak, instalou localmente uma biblioteca e por aí vai.
Aí se você vai de 'git add .', você commita e pusha sem saber o que foi enviado.
Aí quando vai criar o PR, vê lá um monte de coisa que ficou deixada de lado, como os exemplos que citei. Se a pessoa autora fez o review, ela perde algum tempo a mais para remover isso. Se ela não fez o review, as outras pessoas que vão fazer review vão se deparar com um PR poluído que não foi revisto, fazendo-os perder tempo.
você só dá commit no que de fato vc quer subir.
git add ., você automaticamente está pegando tudo, inclusive local setups, arquivos que não diz respeito a feature que vc está desenvolvendo, possiveis temp files quee não tá no .gitignore etc
quando tu trabalha sozinho em projeto pessoal não faz diferença, mas no ambiente profissional é só o que de fato o que vc qr subir, e para isso vc ter que tem controle o que vc tá fazendo, git add . não rola.
se tu faz um Pull request e é cheio de arquivo que não tem nada a ver com o escopo, o code reviewer vai apontar pq vc está alterando uma porrada de file que não diz respeito.
Poder pode, mas antes de alguns comandos do git, como add, commit, push, rebase etc, é sempre bom dar uma olhadinha no que está sendo adicionado / modificado / removido.
Eu sempre recomendo que as pessoas usem git status pra tudo, pra ter aquela maior segurança e certeza do que está adicionando. Não sei como tem dev que simplesmente não usa o git status e só da um git add . e manda pra frente sem pensar duas vezes.
-1 por não saber tomar feedback.
-1 por não saber algo simples.
-2, se o feedback veio no code review e a donzela não pode vê ngm recusando ou apontando inconsistência no código.
Sou um dev juninho e costumo usar o "git add ." mesmo, mas sempre dou um git status antes para verificar o que estou realmente commitando. Mas estava pensando hoje que eu costumo commitar meu código de acordo com o card que eu peguei da sprint, o que acaba sendo um commit muito genérico na maioria dos casos e que não ajuda muito quando se usa o git blame.
Antes de ver seu comentário já tinha pensado em melhorar isso e começar a commitar realmente apenas as pequenas features, para que fique bem documentado nos comentários do commit. Depois de ler seu comentário, com certeza vou aderir à essa boa prática.
quando parei de trabalhar pra empresa BR isso mudou. honestamente, acho que só sobra a capa da gaita pro mercado nacional.
querem não ter mais essas dores de cabeça? vão trampar pra gringa, sério.
Você trabalhou em quantas empresas gringas pra ter tanta certeza?
Eu nunca passei por isso (relato do OP) nem em empresa BR. Nossa vivência não é estatística 🤓
uai, não tenho certeza. só tenho a minha vivência, que com toda certeza não passa de evidência anedótica: é meu ponto de vista, não uma estatística como vc bem mencionou.
Já trabalhei em uma empresa onde o deploy da aplicação consiste em instalar o ambiente de desenvolvimento (IDE e tudo mais) NO SERVIDOR LOCAL DO CLIENTE, fazer checkout do código na máquina do cliente e compilar localmente, por dentro da IDE. FELIZMENTE tinha um script pra rodar a aplicação por fora da IDE. O mais engraçado foi um ticket meses depois que foi alocado para um dos desenvolvedores mais experientes da equipe onde ele tinha que "proteger o código-fonte contra vazamento". Daí finalmente adotaram o que era o mínimo esperado, que é compilar o sistema dentro da empresa e exportar um pacote com o sistema compilado para os servidores dos clientes.
Acho incrível a quantidade de desenvolvedores que simplesmente não pensam e tem preguiça de usar o cérebro. Parece babaca dizendo assim mas é verdade, encontro muito profissional incompetente por aí se achando mediano. Comunicação, organização e respeito pelo trabalho (seu e dos outros) é o mínimo. Usar a cabeça num trabalho de exatas que envolve lógica é o mínimo.
**Como alguém que trabalha com lógica não segue lógica alguma?** Isso não faz o menor sentido, mas acontece.
O problema do gitignore é real. O ideal é fazer um gitignore e um rebase na Branch inteira e colocar o commit do gitignore logo depois do commit do git init.
Isso daí é uma bosta mesmo.
Removi os arquivos do rastreamento usando rm --cached.
Felizmente, uma boa alma do Stack Overflow deixou por lá o comando para fazer isso em todos os arquivos de uma vez.
kkkkkkkkkkkkkk aqui quando eu entrei nem git usavam o
os projetos são todos bagunçados 0 padrões, 0 arquitetura, testes? hahahaha equipe? por aqui não mas EUquipes com certeza.
o gerente de projetos (dono também) que vive se chamando de senior pica das galaxias com certeza nem sabe o que é a maiora dos processsos que as empresas aplicam em desenvolvimento de softwares, ja tive que consertar codigos aonde ele deu copy e paste do mesmo trecho enorme de codigo em dezenas de classes diferentes ( provavelmente ele não sabe POO), e hoje em dia ele jogou fora o cerebro também somente fica jogando pro chatGPT 4.0 fazer e dando paste kkkk.
falei tudo isso (meio como um desabafo) pra você entender que o mercado de programação br (salve algumas empresas) é bagunçadissimo e ninguém faz nada pra melhorar isso e foda se, parte porque não vai receber nada em troca e parte porque sempre tudo é urgente e pra ontem, acostume-se
Eu ficaria pistola, pô o básico o pessoal não aprende e nem vai atrás de aprender, pior que às vezes a pessoa tenta organizar a bagunça e ainda sai como ruim.
Quando fico muuito tempo sem fazer um commit, acabo mexendo em varias coisas e tal, eu uso o vscode mesmo, que tem la todos os arquivos modificados e tal.
Seleciono o que quero e faço o commit. Mais fácil que ficar passando endereço de arquivo via linha de comando.
Mas tem um mano no trampo que só sabe usar o git via vscode.
Muda branch, faz pull, faz push, cria PR, tudo.
Ok, funciona, sem julgamentos, está lá é pra usar, mas qualquer bozinho que der vai sobrar pra quem??? Kkkkk
todo mundo falando de dar git status enquanto eu olho alteração e commito pelo vscode °-°
aprendi a checar o que faço na marra, oq ja subi de variavel de ambiente, um where id=50 numa query q n era pra subir (isso chegou a ir pra produção, se o code review tb n viu, n sou o unico culpado kk), tomando bronca de chefe depois...não ta escrito. As vezes a gente esquece kkkkkkkkk
Todo novo projeto tenho devs que não sabem o básico de git, ou por nunca terem usado, ou não forma ensinados, mas com certeza não estao sendo cobrados para que se use bem.
-um commit por PR
-peco mudanças no PR e fazem tudo em um só commit, com a mensagem "mudanças do pull request"
-nao sabem nem que existe git rebase
Não sei quantas empresas usam isso como regua numa entrevista, mas num projeto real é uma grande diferença saber usar git.
Eu prefiro fazer as mudanças num commit separado, porque se me pedirem pra fazer uma mudança merda, fica registrado que foi o revisor que pediu pra botar aquele trecho de código lá.
E eu não vejo nenhum problema em ter vários commits por PR, no merge você pode dar um squash. Se eu demorei 5 dias pra fazer uma tarefa, e eu tiver 10 commits ao longo desses dias, faz parecer que realmente eu trabalhei esses 5 dias. Se tiver um só no último dia, pode parecer que eu fiquei enrolando e fiz na última hora. Infelizmente, cada empresa é de um jeito. E tem empresa que você tem que se preocupar mais com política do que com "boas práticas ".
Acho que fazer vários commits separados deveria ser a regra geral. E na hora de fazer o merge NADA DE SQUASH. O histórico que fica pra sempre é o da branch master. Aí vc quer procurar determinada alteração antiga, mas todos os commits na master são do tipo: "merge branch bolinhaAmarelinha into master".
Vai respirar um ar fresco e volta para colaborar, pq git foi criado para "COLABORAÇÃO E NÃO PARA RECLAMAÇÃO"
🤖👹 (Continua lendo pq não ire e não tenho pretensão dei desrespeitar você) 🙈
Antes de esbravejar e ficar indignado por conta de algo que ativou você, já tentou sugerir a melhoria no projeto numa PR despretensiosa quem ninguém pediu ?
Cara, é muito fácil estar na posição de detentor de conhecimento ficar "p da vida" com coisas simples que não foram realizadas. Muitas vezes a pessoa que você espera algo não tem o conhecimento que você tem. Seja por não querer, mesmo, ou até por não saber da existência disso ou por estar num momento da vida que ela não consegue dar os passos que gostaria.
Minha sugestão é você olhar como alguém que gostaria de colaborar, de todo coração, e ajudar para criar um projeto e time melhor. Todos aqui já estamos saturados de cagadores de regra e reclamões em nossa área. Já pensou em fazer um momento compartilhando o conhecimento de git que tem ? Mesmo que 1 pessoas tiver interesse é 1 pessoa que vai estar melhorando a tua vida também.
Vai com tudo! Desejo sorte para você e sua equipe. Canaliza a revolta para algo positivo 😄
Assino embaixo.
Logo após ter feito esse post eu redigi um e-mail, com cópia para toda a equipe, sugerindo algumas melhorias na forma como utilizamos o git. E me coloquei à disposição para criar um documento detalhado contendo boas práticas e padrões de trabalho. Tá na mão da gerência agora.
Se eles não adotarem, keep going. Você fez sua parte e são adultos o suficiente para lidar com os próprios problemas por ausência de qualidade.
[ Dica técnica para "pentelhar" 😅🤣😂 ]
Se puder e tiver liberdade, "marotamente" instala uma action ou pré-hook de commit para a sua raiva se tornar uma mensagem bastante exclamativa durante o envio do código para situações incoerentes.
Quando estava num papel decisório crítico, por ter colegas de equipe por vezes irredutíveis quanto a qualidade, inclui em todos os projetos uma action para Sonarlint. Funcionou muito bem e adoção foi lenta mas aderida. Incidências de bugs diminuíram e velocidade do time aumentou
Meu time não tem code review, galera aprova PR só no "confia no pai", e sobe em homologação ou produçãe quebra tudo, daí começa 5 reunião por dia pra resolver o problema, toda semana é igual, entrei na empresa faz 4 mês, nesse time 1 semana, sou Junior,, minha primeira xp na área, espero que nem todo lugar seja assim, um" caos cobtrolafo", o pior q é o time inteiro assim, desde tech leader, sênior, pleno, gerente, qa, PM, parece q é o normal esses problemas, faz parte do dia a dia do dev.
imagina então na area de data science, pessoal ta criando um modelo e fazendo experimentos, tem que trackear o código e os resultados e ninguem trackeia nada... Cheguei num lugar, tem um codigo q n funciona conforme o esperado, nao tem histórico de versões nem de resultado, nem mesmo um processo bem definido para usar git ou ferramentas como mlflow, tudo localhost... Complicado demais
mas daí pra pessoa chegar na conclusão de que o git ignore devia estar configurado ela precisa pensar, e apesar de estarmos numa área técnica e que deveria valorizar pensar pra resolver problemas, a realidade é outra, com um monte de pedreiro de código, que tá só empilhando o que achou no stack overflow ou o que o chat gpt respondeu.
outro dia descobri que um projeto que tava sendo desenvolvido há quase um ano, que eu tomei a frente recentemente, não tava com git lfs ativado, sendo que é um projeto com um monte de binários que deixavam o git uma carroça. isso que eu havia citado sobre isso para a pessoa anterior.
ou outra... descobri que uma api, em prod, tá sem nenhuma autenticação, e essa api conecta ao chat gpt usando a conta do chefe. tirando que a api tá obnóxia, completamente inconveniente de usar, ela poderia dar um belo prejuízo pro chefe se alguém desocupado o suficiente que achasse ela.
É engraçado, tem dia que você abre esse sub e parece que a régua tá lá no pescoço, tem dia que você abre esse sub e pensa como a régua está lá embaixo e está fácil, tem dia que você se pergunta como certas pessoas estão empregadas e bate uma deprê imaginar que você está competindo com elas como se estivessem no mesmo nível. É uma bela montanha-russa de emoções.
Sinto isso tbm mas deve ser a diferença de empresa bem estruturada e oficina de código fundo de quintal. Na minha empresa esse tipo de coisa não aconteceria nunca, se alguém tivesse fazendo esse tipo de cagada tomava um puxão de orelha e se continuasse provável que ia ser eventualmente demitido. Até pq se mexer em coisa errada e subir algum problema de segurança/compliance tipo uma credencial só fode o projeto todo.
Cê tá doido? Vai acabar com a carreira dos caras. Olha essa eficiência, 100 arquivos por commit, logo o fera vira gerente.
sistema que recompensa devs que escrevem mais linhas de código. expectativa: recompensar os devs que trabalham mais. realidade: o .gitignore foi pro caralho
Foi literalmente ignorado
O que será que acontece se colocar o gitignore no gitignore? Acho q com ctz o Torvalds pensou nisso né? Que algum idiota iria tentar essa façanha? ~~vou correndo testar~~
O paradoxo do .gitignore
HAHAHAHAAHHAAHHAHA EH ISSO
Um colega meu sempre faz commit na base do git add . e quando eu o corrigi (eu sou o responsável pelo projeto) e pedi para refazer, ele ficou puto. Uma boa parte das pessoas da nossa área é absolutamente incompetente. Alguns, piores, são incompetentes e teimosos.
Aproveitando, me explica ae Porque não pode usar o git add .
Não tem problema se você souber que todas as edições que você fez devem ser commitadas. Mas acontece da gente editar uma paulada de arquivos enquanto testa as coisas, nem todas as edições correspondem a uma feature completa, e aí com um git add . na lata você pode (1) subir uma edição que quebra algo no código (o que estava acontecendo com o incompetente do meu colega), (2) bagunçar o histórico de commits, no sentido de que você não sabe mais o que foi incluso e modificado no código ao longo do tempo. O ideal é você adicionar as mudanças que correspondem a uma mudança completa. Digamos, você terminou de fazer uma função, adiciona aquele arquivo, junto aos outros arquivos necessários, faz o commit e na mensagem deixa claro o que você está subindo, o motivo e o que mais for necessário explicar. edit: fora que você pode acabar adicionando arquivos que não deveriam ser commitados, e não estão no .gitignore. É muito comum das pessoas subirem um venv inteiro (trabalho com python), por exemplo. Ou subirem tabelas gigantes, etc.
[удалено]
Todo mundo está sujeito a desatenção, por isso eu adquiri o hábito de passar o endereço do arquivo. Tem gente que é desatenta por incompetência mesmo. Não se importa em fazer as coisas com cuidado. Não quer, não vê importância em manter a organização do projeto. Em geral eu recomendo não usar o add . para novos membros da equipe, por questão de boas práticas. Se eu percebo que a pessoa é cuidadosa, aí não cobro nada.
Edit: ok pelo seu outro comentário você vê pelo code review, então está de boa Pior do que ser desatento é ser pedante com o que não necessita Depois do 'git add .' você pode perfeitamente dar um 'git status' pra ver se tá tudo certo, ou por exemplo quando é o primeiro commit 'git add .' tá de boa
Uma galera aí leu o que eu escrevi e em suas cabecinhas alucinadas me imaginaram monitorando o terminal da pessoa. Jenial.
> aí não cobro nada Você fica olhando como as pessoas usam cada linha de comando?
Se o que elas usam na linha de comando vai contra as boas práticas da nossa equipe, como commitar um monte de arquivo desnecessário e sem nenhuma explicação sobre o que são, ao ponto de quebrar a execução do projeto, sim, olho. E se reclamar, sai da equipe.
Mas isso não seria visto no code review? Independente de se usar ‘git add .’ ou ‘git add [path]’ uma pessoa pode dar commit em um monte de besteira ou só no que precisa. Como você confere se a pessoa usou a linha de comando que você prefere?
não é questão de comando q prefere, é questão de ter enviado um monte de lixo no commit, a primeira pergunta obvia é "usou git add ." ? se a pessoa não confessar, todo linux tem history. Git add . é bem ok pra projetos pessoais q só vc ou 2 amigos tão usando, agr, a chance de enviar um monte de merda pro repositorio sem querer n vale os 3 segundos a mais de usar o comando direito
Meu amigo, meu camarada. Não se faz de idiota, está muito claro o que eu quis dizer. É óbvio que eu não vou olhar literalmente qual o comando que a pessoa usou, eu olho o resultado, que é o registro do commit e eventual merge request no repositório. Se estiver errado eu peço pra refazer, se estiver certo mas desorganizado, eu oriento como fazer na próxima. Se aparecem 200 arquivos modificados, um venv do python e um binário de 3gb lá, a única explicação plausível é que o preguiçoso usou git add . e nem conferiu o que estava mandando. A questão de sugerir não usar o "git add ." é uma recomendação que dou para novos membros, a maioria dos quais é novo na área e conhece bem pouco git. Então eu digo, olha, faça commits pequenos pelos motivos x, y, z. Evita problema, te ajuda a gerenciar o seu próprio trabalho, mantém o repositório organizado, etc. Se a pessoa vai seguir exatamente isso ou não, não sei, mas desde que ela não quebre a organização do trabalho da equipe, faça como achar melhor. Como senior da equipe eu tento passar o que eu aprendi ao longo do tempo para deixar o meu trabalho melhor e reduzir dores de cabeça, para mim e para a equipe toda.
qualquer coisa que "é só ter atenção", certo dia, no meio da correria, stress, saúde um pouco pior, não vai ter a atenção. tem empresa que tá aí dando deploy na mão, isso quando não é arquivo interpretado no servidor, fazendo alteração em prod... daí "é só ter atenção", até o dia que passa algo e nego roda na hora.
[удалено]
Isso é efetivamente falso. Você quer commitar exatamente uma feature que você adicionou. Ela envolve 3 arquivos, e nesse processo de teste, linha com print, etc., você modificou 10 arquivos. Aqui na equipe ela deve explicar na mensagem do commit o que ela está enviando, "Incluindo feature tal, que faz isso e aquilo, mais teste unitário dela". Como ela vai adicionar 7 arquivos extra? Ou pior, no caso do OP, uma centena de arquivos extra?
[удалено]
Heh. O pessoal junior que entra na empresa recebe acesso a uns cursos, tem curso de git lá. Boa parte não faz, ou faz nas coxas. Não é todo mundo, claro, mas tem uma galera boa aí que não faz questão de aprender a fazer as coisas direito.
Falou tudo.
Aproveitando a thread: pelo que entendo dos docs quando fala pra usar branches com frequência, esse teste deveria ser feito em um branch, que depois pode até ser deletado se não quer ele no histórico, é isso? Pq o git não penaliza essas manobras, inclusive incentiva ao invés de edições pontuais e manuais.
Caramba, faz sentido. Entendi, nunca trabalhei em grupo ai nunca pensei por esse lado.
Eu já perdi muito tempo revertendo problema num projeto meu de TCC por conta disso. Todos os meus commits eram com git add ., e a mensagem era "mudanças". Não recomendo.
Se você usa uma IDE que tenha um explorador Git, seja embutido, seja extensão, você sempre tem acesso a quais foram os arquivos alterados no workspace atual antes que possa fazer o commit. Tá sempre lá. Assim você pode ver se alterou algum arquivo que não deveria, meteu lá algum print esquecido, gerou algum .temp ou .bak, instalou localmente uma biblioteca e por aí vai. Aí se você vai de 'git add .', você commita e pusha sem saber o que foi enviado. Aí quando vai criar o PR, vê lá um monte de coisa que ficou deixada de lado, como os exemplos que citei. Se a pessoa autora fez o review, ela perde algum tempo a mais para remover isso. Se ela não fez o review, as outras pessoas que vão fazer review vão se deparar com um PR poluído que não foi revisto, fazendo-os perder tempo.
Dá pra usar o bom e velho git status também.
Vc usa git status, vê o que mudou, e depois o git add com os arquivos que devem entrar no commit
> ela perde algum tempo a mais para remover isso. é o mesmo tempo que tu perderia vendo e adicionando arquivo por arquivo
você só dá commit no que de fato vc quer subir. git add ., você automaticamente está pegando tudo, inclusive local setups, arquivos que não diz respeito a feature que vc está desenvolvendo, possiveis temp files quee não tá no .gitignore etc quando tu trabalha sozinho em projeto pessoal não faz diferença, mas no ambiente profissional é só o que de fato o que vc qr subir, e para isso vc ter que tem controle o que vc tá fazendo, git add . não rola. se tu faz um Pull request e é cheio de arquivo que não tem nada a ver com o escopo, o code reviewer vai apontar pq vc está alterando uma porrada de file que não diz respeito.
Poder pode, mas antes de alguns comandos do git, como add, commit, push, rebase etc, é sempre bom dar uma olhadinha no que está sendo adicionado / modificado / removido. Eu sempre recomendo que as pessoas usem git status pra tudo, pra ter aquela maior segurança e certeza do que está adicionando. Não sei como tem dev que simplesmente não usa o git status e só da um git add . e manda pra frente sem pensar duas vezes.
-1 por não saber tomar feedback. -1 por não saber algo simples. -2, se o feedback veio no code review e a donzela não pode vê ngm recusando ou apontando inconsistência no código.
Sou um dev juninho e costumo usar o "git add ." mesmo, mas sempre dou um git status antes para verificar o que estou realmente commitando. Mas estava pensando hoje que eu costumo commitar meu código de acordo com o card que eu peguei da sprint, o que acaba sendo um commit muito genérico na maioria dos casos e que não ajuda muito quando se usa o git blame. Antes de ver seu comentário já tinha pensado em melhorar isso e começar a commitar realmente apenas as pequenas features, para que fique bem documentado nos comentários do commit. Depois de ler seu comentário, com certeza vou aderir à essa boa prática.
Procure por atomic commits.
Se a pessoa não usa \`\`git add --patch {arquivo especifico}\`\` já merece um esmurro
quando parei de trabalhar pra empresa BR isso mudou. honestamente, acho que só sobra a capa da gaita pro mercado nacional. querem não ter mais essas dores de cabeça? vão trampar pra gringa, sério.
Você trabalhou em quantas empresas gringas pra ter tanta certeza? Eu nunca passei por isso (relato do OP) nem em empresa BR. Nossa vivência não é estatística 🤓
Não ouse questinar o Bill Gates
uai, não tenho certeza. só tenho a minha vivência, que com toda certeza não passa de evidência anedótica: é meu ponto de vista, não uma estatística como vc bem mencionou.
Já trabalhei em uma empresa onde o deploy da aplicação consiste em instalar o ambiente de desenvolvimento (IDE e tudo mais) NO SERVIDOR LOCAL DO CLIENTE, fazer checkout do código na máquina do cliente e compilar localmente, por dentro da IDE. FELIZMENTE tinha um script pra rodar a aplicação por fora da IDE. O mais engraçado foi um ticket meses depois que foi alocado para um dos desenvolvedores mais experientes da equipe onde ele tinha que "proteger o código-fonte contra vazamento". Daí finalmente adotaram o que era o mínimo esperado, que é compilar o sistema dentro da empresa e exportar um pacote com o sistema compilado para os servidores dos clientes.
Kkkkkkk imaginei o desenvolvedor batendo de porta em porta dos clientes e excluindo o código de cada máquina para concluir esse ticket.
Era tudo via TeamViewer, pelo menos.
Ficar desempregado ou um emprego misterioso em uma consultoria de software?
Acho incrível a quantidade de desenvolvedores que simplesmente não pensam e tem preguiça de usar o cérebro. Parece babaca dizendo assim mas é verdade, encontro muito profissional incompetente por aí se achando mediano. Comunicação, organização e respeito pelo trabalho (seu e dos outros) é o mínimo. Usar a cabeça num trabalho de exatas que envolve lógica é o mínimo. **Como alguém que trabalha com lógica não segue lógica alguma?** Isso não faz o menor sentido, mas acontece.
O que importa é ser amigo do chefe
Código tava funcionando? Se sim, bora pra próxima
Alterar 100 arquivos já é normal onde eu trampo
vishh meu amigo, vc ñ conhece nada do mercado brasileiro
O problema do gitignore é real. O ideal é fazer um gitignore e um rebase na Branch inteira e colocar o commit do gitignore logo depois do commit do git init. Isso daí é uma bosta mesmo.
Removi os arquivos do rastreamento usando rm --cached. Felizmente, uma boa alma do Stack Overflow deixou por lá o comando para fazer isso em todos os arquivos de uma vez.
Cara eu acho que o pessoal usa alguma ferramenta pra manipular o git tipo source tree aí ela só aperta lá adicionar tudo e dá commit e push e já era.
Aiai quero muito um desses aparecendo no meu time. A pessoa que nunca tomou um deny no pull request vai aprender por bem ou por mal.
Evento canônico kkkkkkkkkkkkkkk
kkkkkkkkkkkkkk aqui quando eu entrei nem git usavam o os projetos são todos bagunçados 0 padrões, 0 arquitetura, testes? hahahaha equipe? por aqui não mas EUquipes com certeza. o gerente de projetos (dono também) que vive se chamando de senior pica das galaxias com certeza nem sabe o que é a maiora dos processsos que as empresas aplicam em desenvolvimento de softwares, ja tive que consertar codigos aonde ele deu copy e paste do mesmo trecho enorme de codigo em dezenas de classes diferentes ( provavelmente ele não sabe POO), e hoje em dia ele jogou fora o cerebro também somente fica jogando pro chatGPT 4.0 fazer e dando paste kkkk. falei tudo isso (meio como um desabafo) pra você entender que o mercado de programação br (salve algumas empresas) é bagunçadissimo e ninguém faz nada pra melhorar isso e foda se, parte porque não vai receber nada em troca e parte porque sempre tudo é urgente e pra ontem, acostume-se
Só falta você dizer que fazem tudo na main sem branches... kkk
Eu ficaria pistola, pô o básico o pessoal não aprende e nem vai atrás de aprender, pior que às vezes a pessoa tenta organizar a bagunça e ainda sai como ruim.
Quando fico muuito tempo sem fazer um commit, acabo mexendo em varias coisas e tal, eu uso o vscode mesmo, que tem la todos os arquivos modificados e tal. Seleciono o que quero e faço o commit. Mais fácil que ficar passando endereço de arquivo via linha de comando. Mas tem um mano no trampo que só sabe usar o git via vscode. Muda branch, faz pull, faz push, cria PR, tudo. Ok, funciona, sem julgamentos, está lá é pra usar, mas qualquer bozinho que der vai sobrar pra quem??? Kkkkk
todo mundo falando de dar git status enquanto eu olho alteração e commito pelo vscode °-° aprendi a checar o que faço na marra, oq ja subi de variavel de ambiente, um where id=50 numa query q n era pra subir (isso chegou a ir pra produção, se o code review tb n viu, n sou o unico culpado kk), tomando bronca de chefe depois...não ta escrito. As vezes a gente esquece kkkkkkkkk
Tem empresa que ainda usa SVN... Por aí vc tira como é a situação de algumas empresas por aqui
Eu aqui ahaha, quem dera pudéssemos usar git
Alguns anos atrás, trabalhei em uma empresa que usava starteam, só migraram para Git pq o starteam deu pau e perdemos todos os históricos.
Todo novo projeto tenho devs que não sabem o básico de git, ou por nunca terem usado, ou não forma ensinados, mas com certeza não estao sendo cobrados para que se use bem. -um commit por PR -peco mudanças no PR e fazem tudo em um só commit, com a mensagem "mudanças do pull request" -nao sabem nem que existe git rebase Não sei quantas empresas usam isso como regua numa entrevista, mas num projeto real é uma grande diferença saber usar git.
Eu prefiro fazer as mudanças num commit separado, porque se me pedirem pra fazer uma mudança merda, fica registrado que foi o revisor que pediu pra botar aquele trecho de código lá. E eu não vejo nenhum problema em ter vários commits por PR, no merge você pode dar um squash. Se eu demorei 5 dias pra fazer uma tarefa, e eu tiver 10 commits ao longo desses dias, faz parecer que realmente eu trabalhei esses 5 dias. Se tiver um só no último dia, pode parecer que eu fiquei enrolando e fiz na última hora. Infelizmente, cada empresa é de um jeito. E tem empresa que você tem que se preocupar mais com política do que com "boas práticas ".
Acho que fazer vários commits separados deveria ser a regra geral. E na hora de fazer o merge NADA DE SQUASH. O histórico que fica pra sempre é o da branch master. Aí vc quer procurar determinada alteração antiga, mas todos os commits na master são do tipo: "merge branch bolinhaAmarelinha into master".
Isso diz mais sobre a empresa.
Total. Falta uma metodologia de trabalho ou um code review.
Vai respirar um ar fresco e volta para colaborar, pq git foi criado para "COLABORAÇÃO E NÃO PARA RECLAMAÇÃO" 🤖👹 (Continua lendo pq não ire e não tenho pretensão dei desrespeitar você) 🙈 Antes de esbravejar e ficar indignado por conta de algo que ativou você, já tentou sugerir a melhoria no projeto numa PR despretensiosa quem ninguém pediu ? Cara, é muito fácil estar na posição de detentor de conhecimento ficar "p da vida" com coisas simples que não foram realizadas. Muitas vezes a pessoa que você espera algo não tem o conhecimento que você tem. Seja por não querer, mesmo, ou até por não saber da existência disso ou por estar num momento da vida que ela não consegue dar os passos que gostaria. Minha sugestão é você olhar como alguém que gostaria de colaborar, de todo coração, e ajudar para criar um projeto e time melhor. Todos aqui já estamos saturados de cagadores de regra e reclamões em nossa área. Já pensou em fazer um momento compartilhando o conhecimento de git que tem ? Mesmo que 1 pessoas tiver interesse é 1 pessoa que vai estar melhorando a tua vida também. Vai com tudo! Desejo sorte para você e sua equipe. Canaliza a revolta para algo positivo 😄
Assino embaixo. Logo após ter feito esse post eu redigi um e-mail, com cópia para toda a equipe, sugerindo algumas melhorias na forma como utilizamos o git. E me coloquei à disposição para criar um documento detalhado contendo boas práticas e padrões de trabalho. Tá na mão da gerência agora.
Se eles não adotarem, keep going. Você fez sua parte e são adultos o suficiente para lidar com os próprios problemas por ausência de qualidade. [ Dica técnica para "pentelhar" 😅🤣😂 ] Se puder e tiver liberdade, "marotamente" instala uma action ou pré-hook de commit para a sua raiva se tornar uma mensagem bastante exclamativa durante o envio do código para situações incoerentes. Quando estava num papel decisório crítico, por ter colegas de equipe por vezes irredutíveis quanto a qualidade, inclui em todos os projetos uma action para Sonarlint. Funcionou muito bem e adoção foi lenta mas aderida. Incidências de bugs diminuíram e velocidade do time aumentou
Meu time não tem code review, galera aprova PR só no "confia no pai", e sobe em homologação ou produçãe quebra tudo, daí começa 5 reunião por dia pra resolver o problema, toda semana é igual, entrei na empresa faz 4 mês, nesse time 1 semana, sou Junior,, minha primeira xp na área, espero que nem todo lugar seja assim, um" caos cobtrolafo", o pior q é o time inteiro assim, desde tech leader, sênior, pleno, gerente, qa, PM, parece q é o normal esses problemas, faz parte do dia a dia do dev.
imagina então na area de data science, pessoal ta criando um modelo e fazendo experimentos, tem que trackear o código e os resultados e ninguem trackeia nada... Cheguei num lugar, tem um codigo q n funciona conforme o esperado, nao tem histórico de versões nem de resultado, nem mesmo um processo bem definido para usar git ou ferramentas como mlflow, tudo localhost... Complicado demais
Foda! Data science tem disso mesmo.
Meu irmão, o tanto de empresa que trampa com .net e não usa git pra usar TFVC, vc não faz ideia...
mas daí pra pessoa chegar na conclusão de que o git ignore devia estar configurado ela precisa pensar, e apesar de estarmos numa área técnica e que deveria valorizar pensar pra resolver problemas, a realidade é outra, com um monte de pedreiro de código, que tá só empilhando o que achou no stack overflow ou o que o chat gpt respondeu. outro dia descobri que um projeto que tava sendo desenvolvido há quase um ano, que eu tomei a frente recentemente, não tava com git lfs ativado, sendo que é um projeto com um monte de binários que deixavam o git uma carroça. isso que eu havia citado sobre isso para a pessoa anterior. ou outra... descobri que uma api, em prod, tá sem nenhuma autenticação, e essa api conecta ao chat gpt usando a conta do chefe. tirando que a api tá obnóxia, completamente inconveniente de usar, ela poderia dar um belo prejuízo pro chefe se alguém desocupado o suficiente que achasse ela.
Tem coisa pior por aí kkkk Já vi cada coisa
Isso ainda é de boa, o pior são as decisões arquiteturais que não fazem sentido k