O que devo incluir no meu repositório de projetos IDE

10

Quero adicionar um projeto que, neste caso, seja criado no Netbeans, mas essa pergunta é geral para a maioria dos IDE. É simplesmente o que devo incluir no meu repositório. Por exemplo, o Netbeans cria uma pasta nbproject, o eclipse cria uma pasta .settings etc., caso eu as inclua no meu repositório, quais são as vantagens / desvantagens de incluir ou não configurações específicas do projeto.

Nesse caso, é um projeto pessoal, por isso não imagino que outras pessoas começarão a trabalhar nele, mas seria bom adicionar o mínimo de configurações do projeto, para que o próprio projeto seja fácil começar a trabalhar em máquinas diferentes.

— Daniel Figueroa
fonte

Considere ferramentas como o maven com seu plugin eclipse (ou outro ide) para configurar o ambiente adequado em vez de incluir o seu próprio.

@MichaelT Sinto muito, mas eu realmente não sigo, você se importaria de expandir isso?

— Daniel Figueroa

O uso de uma ferramenta de construção e a configuração da ferramenta de ambiente para o ide permitem garantir que a configuração seja a mesma, independentemente da plataforma (ou ide). Até desenvolvedores individuais têm vários ambientes (ide vs build). Isso simplifica a pergunta para uma pergunta respondida "não faça check-in de nada específico do seu ambiente porque eles são código gerado". - o mesmo racional em que você não verifica as classes .java geradas pelo jaxb, mas as instruções (arquivo build.xml ou .pom) sobre como construí-las.

Se for "original", é necessário fazer backup. Se ele mudar e aqueles precisarem de rastreamento e for original, deverá ser controlado por revisão. O problema - como estruturar o repositório de repositório para que a fonte permaneça sua fonte, enquanto as configurações da cadeia de ferramentas não poluem o repositório de origem. Mesmo se aplica a recursos como imagens, som e vídeo ....

— mattnz

4

Realmente depende de quais dados são e deve ser decidido caso a caso, talvez até para arquivos individuais. Dê uma olhada no conteúdo desses arquivos. Mais frequentemente, você pode dizer o que eles significam. Coisas como a posição e o tamanho das janelas do IDE são algo que você não deseja no controle de origem.

Mas alguns dos arquivos de projeto do IDE são metadados vitais do projeto. Não conheço bem o Netbeans, mas, para o eclipse, o arquivo .project informa ao IDE qual é o nome do projeto, que é um projeto da web Java etc., e o arquivo .classpath contém informações sobre pastas e bibliotecas de origem. Alguns arquivos no diretório .settings podem ser igualmente importantes, por exemplo, org.eclipse.core.resources.prefs contém informações sobre qual codificação deve ser usada para quais arquivos.

Como metadados do projeto, esse material merece muito a versão no controle de origem.

Alguns IDEs podem importar metadados do projeto de outros IDEs. Seria ainda melhor tê-lo de uma forma que não esteja vinculada a um IDE específico.

Para Java, existe uma coisa: Maven . Ele impõe convenções fortes à estrutura do projeto e permite especificar os metadados do projeto (como dependências da biblioteca) em um ponto (um arquivo chamado pom.xml, que está no diretório principal do projeto e, é claro, no controle de origem). Existem plugins que criam arquivos de projeto IDE a partir da configuração do Maven e outros que podem automatizar o processo de criação do projeto ou fazer praticamente qualquer coisa. Às vezes, parece que torna as coisas desnecessariamente complexas e leva algum tempo para aprender, mas os benefícios geralmente valem a pena.

— Michael Borgwardt
fonte

1

se não estou errado, o Maven é independente do IDE. Nesse caso, como ele contém configurações / metadados do projeto, ele definitivamente deve incluir no repositório, mas não os "arquivos de projeto IDE" aos quais o OP parece se referir especificamente.

— Bleeding Fingers

@ hus787: o que quero dizer é que esses metadados são importantes o suficiente para estar no repositório e, embora sejam ótimos quando você os possui de forma independente do IDE, quando esse não é o caso, ainda é melhor tê-lo do que não Tê-lo.

— Michael Borgwardt

2

Isso realmente depende do tipo de informação que você gostaria de ter no repositório. Se você deseja tudo sobre os arquivos que você abriu e estava editando no momento da confirmação, e você é o único que usa o repositório, vá em frente e confirme tudo, mas saiba que pode não funcionar em outra máquina .

Se você deseja compartilhar seu código com outras pessoas que podem não estar usando o mesmo IDE, basta confirmar o código em si, sem nenhuma implementação específica do projeto.

Se você souber que todos usam o mesmo IDE, provavelmente poderá incluir qualquer coisa que não seja específica do computador, ou seja, arquivos / pastas de configuração apenas para o próprio IDE, para que eles já possam importar o projeto como o O IDE espera isso.

— Ampt
fonte

2

Os artefatos que ajudam seu desenvolvimento e não são úteis para a construção / liberação ou o próprio projeto não devem ser incluídos. O repositório deve ser limpo e arrumado e ter apenas coisas relevantes para o projeto, não para o seu ambiente . O repo deve ser um reconhecimento dos seus hábitos. E, em segundo lugar, isso irá incomodá-lo desnecessariamente quando fizer algo parecido com git status... mas ei, eu nunca fiz alterações ... ahh, ignore isso.

Deixe-me dar um exemplo mais prático (usarei gitaqui como ferramenta):

Você nunca desejaria que um submódulo (recursivo) dentro do seu repositório principal tenha um material específico do IDE (isso também pode interferir no ambiente do projeto principal) porque tudo o que importa é o código que foi escrito por outra pessoa (ou você) e de uso dentro do projeto atual. Não é o ambiente em que foi desenvolvido. Você provavelmente também não quer fazer isso com outra pessoa.

Para poder usar sua configuração em uma máquina diferente, sugiro pesquisar dentro do seu IDE e ver que suporte ele fornece para essas coisas. Emacs tem inite servidor Emacs também. Ou você pode criar sua macro ou script personalizado ( .sh) que faz a configuração automaticamente.

— Dedos Sangrentos
fonte

-1: discordo completamente. Essas informações podem ser muito importantes e úteis, e seu repositório definitivamente deve incluir essas informações.

— Michael Borgwardt

@MichaelBorgwardt e se o OP mais tarde planeja mudar para algum outro IDE. Como essas configurações específicas do IDE do projeto serão entendidas na outra? Um exemplo seria muito apreciado.

— Bleeding Fingers

Alguns IDEs podem importar metadados do projeto de outros IDEs. Mesmo que não possam, esses arquivos geralmente são legíveis por humanos e tê-lo é melhor do que não tê-lo.

— Michael Borgwardt

E o que acontece se você fubar completamente sua área de trabalho (aconteceu comigo recentemente) e não puder reverter as alterações definindo manualmente as coisas como você pensava que eram antes? Provavelmente economizei horas porque a área de trabalho foi registrada. Sem mencionar que em alguns IDE, a área de trabalho incluirá itens como modelos de código que seriam muito difíceis de configurar manualmente todas as vezes.

— Amy Blankenship

@AmyBlankenship esse é o meu ponto, é o seu espaço de trabalho, como você pode ter certeza de que ele não interfere nos outros (eles puxam e, de repente, o espaço de trabalho é substituído pelo seu), é melhor manter essas coisas em uma ramificação local separada ou você pode usar o mercurial para o seu espaço de trabalho específico VC do projeto pessoal e git para o projeto VC. Sobre os modelos de código, acho que seu IDE não está maduro o suficiente (ou ainda não foi explorado adequadamente) e, se você está dizendo que os modelos são específicos do projeto, acho que você deve procurar padrões no seu código.

— Bleeding Fingers

1

Se for um projeto pessoal, digo armazenar as configurações no controle de origem. Pessoalmente, nada mata mais a minha motivação para um projeto do que a criação de um ambiente de desenvolvimento novamente.

Quando há mais pessoas envolvidas, não coloco essas coisas no controle da fonte. Na minha equipe, temos uma mistura de IntelliJ, Sublime Text e Eclipse em uso. Os arquivos IDE apenas aumentam a confusão e resultam em puxar confirmações para esses arquivos de outras pessoas para um IDE que você não usa.

Além disso, seu projeto não deve depender do IDE de qualquer maneira. Um servidor de construção não inicializará o Eclipse para compilar seu produto, portanto, ele já deve estar livre de IDE. Um ponto mais secundário: elimina a organização pessoal dentro do projeto. Por exemplo, no IntelliJ, gosto de usar muitos módulos em nosso projeto. Ninguém mais usando o IntelliJ se preocupa com isso, porque não armazenamos os arquivos .iml (módulo).

Se sua equipe estiver usando o mesmo IDE, será melhor, mas alguém confirmará uma entrada .classpath incorreta porque eles usaram um caminho absoluto. Agora, todos que usam o IDE se preocupam com isso.

Claro, a desvantagem é que há mais configurações quando alguém faz check-out do projeto. Eu acho que vale a pena. Usamos o Ivy para gerenciamento de dependências e temos informações sobre configuração, dependências, etc. Apesar desse custo inicial, acho que vale a pena manter as configurações do IDE fora do controle de origem.

— Kryptic
fonte