#git #version-control #github #commit
#git #контроль версий #github #фиксация
Вопрос:
Я скоро начну проект для Android, чтобы узнать об Android, и буду изучать git вместе с ним.
Мне было любопытно, что должно быть в первом коммите? Должно ли это быть просто оболочкой приложения? Например, может быть, файлы по умолчанию с информацией о приложении и тому подобное? Может быть, создать файлы классов, которые потребуются, но оставить их относительно пустыми?
Те же вопросы для большинства проектов, кроме этого. Если я выражаюсь слишком расплывчато, дайте мне знать, и я постараюсь прояснить все, что вам нравится.
Комментарии:
1. Это ваше предпочтение, но я обычно просто помещаю оболочку или мой первый «сеанс» работы в первый коммит.
2. Я часто просто помещаю
.gitignoreв первый коммит.
Ответ №1:
Ваш первый коммит должен быть некоторой базовой структурой (т.е. даже не заполняйте структуру — просто зафиксируйте голые кости). Все коммиты должны содержать относительно небольшие изменения. Это поможет вам отслеживать все изменения на этом пути (особенно если вы документируете, что каждый небольшой коммит включал в себя выполнение / изменение в разделе информации о фиксации). Кроме того, вы никогда не захотите совершать что-то, что не работает…
Приветствия!
Комментарии:
1. Небольшие изменения, например, в чем? Один совет, который я получил некоторое время назад, заключался в том, чтобы фиксировать только рабочие сборки, что имеет смысл. Может быть, просто прокомментируйте вещи, которые не работают правильно, если они есть.
2. @Portaljacker Любые небольшие изменения. Например, если у меня есть программа с 2 простыми классами — после добавления конструктора я бы зафиксировал. После этого я бы заполнил конструктор, а затем снова зафиксировал. Я стараюсь делать как можно больше небольших коммитов, чтобы все было чистым и понятным. Это также упрощает исправление, если вы допустили ошибку…
3. @Portaljacker Кроме того, да, вы никогда не должны комментировать код, который не работает. Вы могли бы прокомментировать это — я бы посоветовал вам заставить его работать, прежде чем вы его зафиксируете (вместо того, чтобы просто комментировать). Это особенно работает, если вы создаете это в небольшой команде или самостоятельно. Вы можете работать над своим кодом раздел за разделом (с небольшими изменениями) и продолжать его наращивать. Имеет ли это смысл? Надеюсь, что так.
4. Я думаю, так, разделение его на разделы будет самой сложной частью, я думаю. Я создаю приложение reddit для Android не для того, чтобы сделать приложение лучше, а просто для того, чтобы сразу изучить кучу вещей.
5. @Portaljacker Это довольно крутая идея. Продолжайте в том же духе
Ответ №2:
В основном, вы просто хотите сделать это как можно скорее. Вы хотите использовать управление версиями с самого начала вашего проекта. Просто добавьте и зафиксируйте то, что у вас есть в данный момент. Структуры каталогов и файла readme / source более чем достаточно.
Ответ №3:
Имейте в виду, что все, что вы добавляете в первый коммит, вам будет сложно переписать rebase , если вы решите использовать позже. Я бы поставил базовый README в качестве вашего первого коммита.
Ответ №4:
На самом деле это не имеет значения, но мое предложение было бы:
Сначала зафиксируйте пустую структуру каталогов, которую вы будете использовать, возможно, с одним исходным файлом и / или сценарием сборки. Важно, чтобы вы фиксировали как можно раньше, чтобы у вас была полная история в репозитории. (Другими словами, не работайте в течение часа перед выполнением первого коммита).
Комментарии:
1. Это лучший ответ IMO. Если первый коммит — это что-то иное, чем почти пустой материал, будущие разработчики вскоре попытаются найти документ для изменений кода и придут к описанию «начальной фиксации» для большого количества изменений кода. Это довольно неприятно.