Мерзавец основной рабочий процесс [дубликат]
Возможный дубликат:
ошибка нажатия мерзавца' [удаленный отклоненный] ведущее устройство-> ведущее устройство (ответвление в настоящее время проверяется)'Я плохо знаком с Мерзавцем и пытающийся использовать его для локального проекта чаш Грааля.
Шаги я следовал:
- создайте проект чаш Грааля
- перейдите к каталогу проекта и
git init- Добавьте все файлы в проекте в районе сосредоточения войск и фиксации.
Состояние мерзавца в repo дает ниже сообщения
BXX@BXX-PC /c/Work/Grails/projects/yyy/tables (master) $ git status # On branch master nothing to commit (working directory clean)При попытке сохранить его как основное ответвление, внесите изменения путем клонирования repo и более позднего нажатия изменения назад. Для этого
- В моем IDE, контроль проект (IntelliJ).This на самом деле клонируют проект к другому dir.
- Внесите изменения и фиксируйте проект
Продвиньте локальные изменения в ведущем устройстве.
15:41:56.249: git push -v origin master Pushing to c:/Work/Grails/projects/xxx/tables remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD.Клонированное repo состояние
$ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean)Помогите мне с пониманием этого. Есть ли лучший рабочий процесс для следования. Я могу инициализировать repo через Intellij и пытаться работать над основным ответвлением. Все еще уверенный что не так выше.
спасибо.
3 ответа
Прежде всего, вам не нужно клонировать локальный репозиторий. Вы можете использовать ветки для разделения разработки в одном репозитории.
Git - это распределенная VCS, и если у вас есть опыт работы с Subversion или CVS до этого, вам нужно передумать.
Git очень гибок, и с ним можно использовать разные рабочие процессы. Клонирование репозиториев больше нужно для командной работы, а не для локальной разработки (ИМХО).
Филиалы - хорошая альтернатива для вас.
См. Давайте установим ветвь master вашего репозитория для кода , готового к производству . Создадим еще одну ветку для development :
$ git checkout -b development master
Теперь вы работаете над веткой development .
Вы можете использовать разные ответвления для каждой функции, которую хотите разработать. Это очень просто и полезно.
Представим, что вы хотите реализовать какую-то новую функцию, вам нужно создать новую ветку:
$ git checkout -b newfeature development
Теперь вы можете работать со своим кодом, добавлять файлы, делать коммиты и так далее.
Затем вам нужно объединить вашу новую разработанную функцию с веткой development :
$ git add .
$ git commit -m "My last changes for the new feature"
$ git checkout development
$ git merge newfeature
Теперь ваш новый код из ветки newfeature объединен с веткой разработка ветка.
Когда-нибудь в будущем, когда вы решите, что ваш код в ветке development достигнет определенного рубежа, вы можете объединить все изменения из development в master ветвь.
Это очень простой рабочий процесс, он может быть полезен для многих ветвей.
Мой вам совет: узнайте больше о git, ветвлении, хранении (очень-очень-очень полезно для быстрых исправлений).И через некоторое время вы получите большие усилия от использования git.
Удачи.
Проблема в том, что вы пытаетесь перейти на репо, отличное от чистого. Не-голое репо - это репо, имеющее связанное с ним рабочее дерево (то есть файлы фактически извлекаются на диск). По умолчанию Git не позволяет вам нажимать на репозиторий, не являющийся чистым; нажатие на репозиторий, отличное от чистого, только обновляет внутренние структуры данных Git и не изменяет , а не рабочее дерево (файлы на диске), что означает, что если вы затем вернетесь в репо, которое вы переместили, и запустите работая с файлами, вы будете работать со старыми копиями файлов. Естественно, это вызовет проблемы, когда вы попытаетесь зафиксировать свои изменения.
Лучший способ сделать это - отправить в репозиторий bare , который создается путем передачи Git флага - bare при создании репозитория:
$ mkdir new_repo
$ cd new_repo
$ git --bare init
Конечно, в чистом репо не будет извлеченных файлов, поэтому вы не сможете работать с ним (сначала вам придется клонировать его).
Если вы просто используете репозиторий Git для локальной разработки (а не делитесь репозиторием Git и не обслуживаете его), у вас нет , чтобы иметь удаленное репо для отправки; вы можете работать с единственной копией локального репо.
Это наиболее ясное и полное описание успешного рабочего процесса git. Он охватывает в основном то, что предлагает Сергей, с добавлением очень полезной графики.
Автор также предлагает при слиянии включить тег - no-ff , чтобы записывать тот факт, что у вас есть ветвь функции в истории.