Базовый рабочий процесс Git

Во-первых, вам не нужно клонировать локальный репозиторий. Вы можете использовать ветки для разделения разработки в одном репозитории.

Git - это распределенная VCS, и если у вас был опыт работы с Subversion или CVS до этого, вам нужно передумать.

Git очень гибкий, и с ним можно использовать разные рабочие процессы. Клонирование репозиториев больше нужно для командной работы, а не для локальной разработки (ИМХО).

Филиалы - хорошая альтернатива для вас.

Видеть. Давайте установим главную ветвь вашего репозитория для готового кода. Создадим еще одну ветку для разработки:

$ git checkout -b development master

Сейчас вы работаете над веткой разработка.

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

Представим, что вы хотите реализовать какую-то новую функцию, вам нужно создать новую ветку:

$ git checkout -b newfeature development

Теперь вы можете работать со своим кодом, добавлять файлы, делать коммиты и так далее.

Затем вам нужно объединить вашу новую разработанную функцию с веткой разработка:

$ git add .
$ git commit -m "My last changes for the new feature"
$ git checkout development
$ git merge newfeature

Теперь ваш новый код из ветви newfeature объединен с ветвью development.

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

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

Мой вам совет: узнайте больше о git, ветвлении, хранении (очень-очень-очень полезно для быстрых исправлений). И через некоторое время вы получите большие усилия от использования git.

Удачи.

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

Лучший способ сделать это - отправить в чистый репозиторий, который создается путем передачи флага --bare в Git при создании репозитория:

$ mkdir new_repo
$ cd new_repo
$ git --bare init

Конечно, в голом репозитории не будет извлеченных файлов, поэтому вы не сможете работать с ним (сначала вам придется клонировать его).

Если вы просто используете репозиторий Git для локальной разработки (а не предоставляете общий доступ к репозиторию Git и не обслуживаете его), у вас не требуется иметь удаленное репо для отправки; вы можете работать с единственной копией локального репо.

Это наиболее четкое и полное описание успешного рабочего процесса git. Он охватывает в основном то, что предлагает Сергей, с добавлением очень полезной графики.

Успешная модель ветвления Git

Автор также предлагает при слиянии включить тег --no-ff, чтобы фиксировать тот факт, что у вас есть ветка функции в истории.

Я оказался здесь, когда пытался решить ту же проблему, к счастью, есть гораздо лучший ответ:

Ошибка Git push '[удаленное отклонение] master - ›master (ветка в настоящее время проверена) '

Вы должны проверить это. Тем более, что попасть в такую ​​ситуацию довольно легко. Для меня все, что я сделал, - это создал каталог и git init, чтобы создать мой новый «общий репозиторий». Это было на USB-ключе, потому что наша сеть полностью заблокирована, и мы пока не можем поделиться каталогом или получить доступ к GitHub.

Затем я скопировал весь наш исходный код в этот каталог, добавил его, зафиксировал его, а затем клонировал полученный репозиторий на свой локальный диск, так что теперь он стал моим источником. Я подумал, что позже смогу сделать GitHub удаленным и отказаться от общего хранилища USB. Однако мое первое изменение на локальном диске и попытка нажать на удаленный (репозиторий ключей) дали мне сообщение, потому что репозиторий ключей не был «пустым». Все исходные файлы все еще были там.

Проконсультируйтесь с наиболее высоко оцененным ответом на вопрос, связанный с, чтобы узнать, что делать. Суть в том, что вы устанавливаете флаг в общем репозитории, чтобы он считал его пустым, а затем удаляете из него все, кроме подкаталога .git, и ваш push будет работать.