Когда я должен сделать репозиторий для моего проекта? - PullRequest
1 голос
/ 08 октября 2011

Я изучал использование Mercurial для управления версиями и хотел попробовать. Я планирую сделать проект самостоятельно, чтобы помочь мне изучить C ++, пришедший из Java, и подумал, что было бы неплохо попробовать с ним управлять версиями. Вероятно, это будет игра или какое-то простое приложение, не уверенное с графическим интерфейсом или нет.

Проблема в том, что я мало знаю об управлении версиями. Когда в проекте самое подходящее время для создания хранилища? Должен ли я сделать это прямо сейчас? Как часто я должен совершать коммиты?

Я буду использовать Netbeans для своей разработки, так как она кажется довольно хорошей, также есть встроенные элементы управления Mercurial, но что я должен установить в .hgignore для своего проекта? Я предполагаю, что репозиторий будет всей папкой, которую создает Netbeans, но что я должен игнорировать?

Бонусные вопросы : Я буду использовать Bitbucket для хостинга / резервного копирования, должен ли я сделать проект публичным? Почему, почему нет? Также это сделало бы это с открытым исходным кодом? Должен ли я беспокоиться о присоединении лицензии? Потому что я понятия не имею, как работают лицензии и тому подобное. С другой стороны, я искренне сомневаюсь, что сделаю все, что кто-нибудь захочет скопировать слишком сильно.

Ответы [ 4 ]

6 голосов
/ 08 октября 2011

На репо:

Вы должны использовать репозиторий VCS как можно скорее.Он не только позволяет создавать резервные копии за пределами сайта, но и позволяет отслеживать изменения.Чтобы узнать, когда была введена ошибка.

Наличие VCS, особенно распределенной VCS, такой как Mercurial, изменит ваш код.Вам не нужно быть осторожным, чтобы не сломать вещи, потому что у вас всегда есть старая версия, к которой вы можете вернуться.Если по прошествии нескольких недель или месяцев вы решите, что определенный курс разработки был плохой идеей, вы можете перемотать все назад до какого-то предыдущего момента.

Обычно вы должны совершать каждый день или каждыйраз вы закончите задачу.Например, у вас может быть 4-часовое задание «написать этот класс и заставить его работать».Вы совершаете после этого.Когда вы закончите на день, вы делаете это.Я бы не советовал делать коммит в некомпилированном состоянии, поэтому вам следует постараться остановиться на тот день только тогда, когда все еще собирается.

Что касается игнорирования, вы должны игнорировать вещи, которые вы не намереваетесь делатьсовершить.Вещи, которые вы не хотели бы в репо.Сгенерированные файлы, временные файлы, вещи, которые вам не нужны.

В репо должно быть 100% информации, необходимой для создания проекта с нуля (за исключением внешних зависимостей).

По лицензиям:

Я бы сказал, что очень грубо создавать публичный репозиторий без какой-либо лицензии.Без лицензии это означает, что любой, кто даже вытаскивает из репо (что вы и предлагаете, обнародовав), является нарушением ваших авторских прав без прямого, явного разрешения с вашей стороны.

Так что либо посмотрите накак работает авторское право и выберите лицензию, чтобы выпускать свои материалы или сохранять свои репозитории закрытыми.

4 голосов
/ 08 октября 2011

В тот момент, когда вы это понимаете, обычно. Нет никакого штрафа за то, что вы сразу же положили все, что у вас есть, в VCS, и, кто знает, вы, возможно, захотите эту превосходную прототипную версию позже в будущем. Если вы не собираетесь проверять большие медиа-файлы (не), мой ответ: прямо сейчас.

Что касается того, как часто совершать, это личное предпочтение. Я использую git, и, насколько я понимаю, нет проблем с проверкой каждый раз, когда вы вносите какую-то единицу значительных изменений. Чем больше снимков по пути, тем легче будет отследить ошибки позже.

Ваш .hgignore зависит от вас. Вы должны решить, что для версии, а что нет. Как правило, любые файлы, сгенерированные во время компиляции, вероятно, не должны регистрироваться.

Кроме того, если вы публикуете его, пожалуйста, приложите лицензию. Неважно, что это, но это делает всех боссов и юристов в мире счастливыми, когда они знают, что они могут и не могут сделать с вашим кодом. Наконец, пожалуйста, не публикуйте что-либо для публики, если только вы не думаете, что кто-то другой извлечет из этого пользу. Интернет уже страдает от информационной перегрузки.

0 голосов
/ 08 октября 2011

Исходя из моего опыта работы с git, я бы порекомендовал следующее:

  1. Создание хранилища вместе с проектом.
  2. Фиксация как можно чаще с подробными комментариями
  3. Если вы хотите проверить новую идею - создайте ветку.Если идея удалась, объедините ваш код с основной веткой.Если идея не удалась, вы можете просто отказаться от ветки.Вероятно, это самая важная идея.
  4. Поместите имена объектных файлов, исполняемых файлов и файлов резервных копий редактора в список игнорирования.
0 голосов
/ 08 октября 2011

Фиксируйте рано и часто.

С распределенными VCS, такими как hg или git, на самом деле нет причин не запускать репо, прежде чем вы даже напишите какой-либо код.Если вы решите отказаться от своего проекта, вы всегда можете удалить свое хранилище, прежде чем публиковать его на любом хостинг-сайте, который вы используете.Чем чаще вы делаете коммит, тем легче будет отточить, где вы позже напутали (вы это сделаете).

Материал, который нужно вставить в ваш файл игнорирования, будет файлами сборки и всем, что ваша IDE периодически генерирует., как пользовательские настройки и кеш тегов.Вы не хотите навязывать свои предпочтения кому-либо еще, и вам не нужно создавать коммит каждый раз, когда вы меняете положение окна в IDE.То, что находится в репо, должно быть минимумом, который кто-то должен был бы иметь для работы над вашим проектом.

Если вы просто делаете небольшой проект для изучения, то я не буду беспокоиться о лицензиях или наличиичастное репо.Вы всегда можете добавить лицензию позже.В качестве альтернативы просто выберите разрешительную лицензию и воспользуйтесь ею.

...