Как я могу внести свой вклад в репозиторий git между двумя разными местами без конфликтов слияния

Question

Я единственный разработчик в проекте.Например, скажем, у меня есть следующий сценарий:

Office A - внести изменения в код, commit затем push

Office B - попробоватьна тянуть изменения, но если какие-либо изменения внесены, он жалуется.Я хочу забыть обо всех внесенных изменениях и получить последнюю версию.

По сути, я переключаюсь между офисами A и B и каждый раз хочу зафиксировать изменения в удаленном репозитории, а затем снова получать эти изменения изследующий офисGit будет жаловаться, так как в рабочей копии могут быть небольшие изменения.Я использовал git reset --hard с последующим pull , но это как-то не правильно.Я тоже смотрел на stash , но, похоже, что-то сохраняет изменения для дальнейшего использования.

Количество команд для git кажется изумительным!

Answer 1

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

Answer 2

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

Причина, по которой git жалуется вам , заключается в том, что это требуется моделью ревизий: предположим, на машине A вы сделали коммит с помощью хэша "abcdef". Чтобы иметь возможность обмениваться наборами изменений между репозиториями, как вы хотите, коммит "abcdef" должен быть точно везде одинаковым. На машине B, когда вы извлекаете этот коммит в ваши локальные изменения, он может поместить этот коммит в историю в каком-то конкретном месте, но он не может смешать , который фиксирует ваши локальные изменения. Это приведет к коммиту «3dea12», который совершенно другой.

Git может попытаться смешать ваши изменения на лету, как это делает Subversion. Рассмотрим, однако, если вы совершили коммит шесть раз: теперь вам нужно объединить шесть раз, по одному разу для каждого (неделимого) коммита, примененного на другой машине. Subversion обходит это, суммируя изменения в общем двоичном объекте diff, который затем пытается поместить поверх ваших локальных изменений. Иногда это работает, но некоторые слияния становятся немного странными, и не позволяет вам вести аккуратную историю изменений, которые никогда не меняются, которые предлагает git.

Чтобы решить вашу проблему , вот ваша стратегия вытягивания на машине B:

$ git stash       # Set your uncommitted changes aside for a moment
$ git pull        # Pull in the new changes
                  # <resolve conflicts, if they happen>
$ git stash pop   # Bring back your uncommitted changes, fixing ambiguous
                  #     merge pieces as necessary.

По сути, это стратегия "не волнуйся, git stash не страшно". :)

Я думаю, важно отметить, что вам придется объединить . Хорошие практики разработки, сохранение небольших изменений и т. Д. Могут сделать слияния реже, но вам все равно придется иногда слияния.

Между прочим, вы хотите, чтобы жаловались. Если ваша рабочая копия чистая (нет необходимости в тайниках), вы смешиваете одну историю с другой. Git найдет места, где вам нужно слиться, и спросит вас, что делать. Это довольно четкий процесс. Если бы это место было связано с локальными изменениями , а также , история стала бы очень запутанной. По сути, это будет слияние вещей из прошлого с вещами из «будущего», которое в данном случае является вашей незафиксированной работой (которая, вероятно, изменится!).

В свете этого, вот ваш другой вариант:

$ git commit -m "..."    # Commit your local changes, making them part of history.
$ git pull               # Clean working copy! (maybe merging required)

Answer 3

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

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

Таким образом, вы должны начать использовать отдельные ветви для каждой разрабатываемой вами функции. Как только он закончится, вы можете объединить ветку обратно в mainline / master / что угодно и просто удалить ветку. Преимуществом этого подхода является то, что вы можете разрабатывать свои функции независимо друг от друга и не должны испытывать Bij преждевременно.

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