Git основной рабочий процесс

Ответ 1

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

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

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

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

См. Позвольте установить ветвь master вашего репозитория для готового к выпуску кода. Позвольте создать еще одну ветку для разработки:

$ 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 до master.

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

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

Удачи.

Ответ 2

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

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

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

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

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

Ответ 3

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

Успешная git ветвящаяся модель

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

Ответ 4

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

Git push error '[удаленный отказ] master → master (ветвь в данный момент проверена) '

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

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

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