#git #sublimemerge
Вопрос:
Должно быть, я что-то упускаю, почти всегда, когда я собираюсь нажать на свою фиксацию, я буду заблокирован, потому что кто-то другой нажал фиксацию прямо передо мной, и мои изменения (моя фиксация) больше не основаны на кончике пульта дистанционного управления.
В этой ситуации я снова клонирую репо (в другой папке) и снова вручную изменю каждый файл, зафиксирую и надеюсь, что никто больше не нажимал прямо передо мной. Иногда это случается, хотя, и поэтому я клонирую репозиторий в другую папку во второй раз, и та же история повторяется.
Наблюдая за историей фиксации, при моем подходе я вижу чистую линию, которая мне нравится.
Я заметил, что другие разработчики в проекте часто совершают коммит слияния после своих собственных коммитов. Я думаю, это потому, что они сталкиваются с той же ситуацией, что и я (кто-то другой толкнул раньше, и изменения больше не основаны на подсказках), но они справляются с ситуацией по-другому (используя фиксацию слияния).
Проблема в том, что эти коммиты слияния (по крайней мере, так, как они выполняются) ничего не вводят, они просто повторяют изменения из предыдущего коммита, потому что, похоже, разработчик не выпустил pull перед push. Другими словами, я скажу, что линия истории фиксации грязная.
Я предполагаю, что подход с фиксацией слияния быстрее обрабатывать, чем снова клонировать репо и снова изменять каждый отдельный файл. Но линия истории фиксации грязная.
В проекте используется только одна ветвь, мастер. И размещается в общей папке в локальной сети.
Я обычно делаю git из командной строки, но в эти дни я использую https://www.sublimemerge.com почти все время.
Как я могу улучшить свой рабочий процесс фиксации/push? Должен ли я использовать другие инструменты?
Комментарии:
1. Всякий раз, когда вы не можете нажать, вы снова клонируете репо? Если вам не нравятся коммиты слияния, почему бы не перебазировать?
2. перебазирование после слияния определенно не требует повторного клонирования репо! :-О, это такой перебор.
3. хорошо… Я думаю, вам следует научиться использовать ветви и выполнять базовую перебазировку/слияние. В качестве примечания, клонирование, а затем перемещение файлов- неправильный способ сделать это. Если в этих файлах есть изменения, внесенные другими разработчиками в ветку после того, как вы запустили свою собственную ветку, вы возвращаете (неохотно/неосознанно) эти изменения. Правильная перебазировка/слияние позволяют избежать этого.
Ответ №1:
Для начала было бы лучше, если бы вы занимались разработкой в другой ветке. Даже если другие ваши разработчики настаивают на том, чтобы делать это таким образом, это не мешает вам ветвиться.
- Создайте новую ветвь.
- Выполняйте свою работу, посвящая себя этой отрасли по мере необходимости.
- Переключиться на мастер
- Внесите новые изменения.
- Объедините свою ветвь в главную
- Внесите изменения.
В качестве альтернативы, если вы действительно настаиваете на том, чтобы не использовать ветви, и вам не нравятся эти коммиты слияния, вы можете выполнить перебазирование.
Комментарии:
1. Я предвижу, что меня заблокируют на шаге 5. Объедините свою ветвь в master. И поскольку я нахожусь в своей собственной ветке для многих коммитов, с этим, вероятно, будет еще сложнее справиться. Разве это не так?
2. @KcFnMi: Ты не должен. Я полагаю, что если ваша команда плохо умеет общаться, есть вероятность, что вы столкнетесь с конфликтами слияния.
3. Если вы действительно хотите полностью избежать коммитов слияния, вы можете перебазировать свою ветвь поверх главной, хотя это может быть сложно с общедоступными ветвями.
4. О, кажется, я уловил идею. Интерфейс между каждой ветвью должен быть очень четким. Допустим, у проекта есть три компонента/папки, тогда мы создадим ветвь для каждого?
Ответ №2:
В этой ситуации я снова клонирую репозиторий (в другой папке) и снова вручную изменю каждый файл,
Это довольно утомительно.
Вместо этого сделайте это:
git fetch
git rebase -i origin/master
Это автоматически объединит все изменения, внесенные другими пользователями. В тех случаях, когда изменения вступают в противоречие с вашими, это позволит вам разрешить эти конфликты.
Затем, наконец,
git push
Комментарии:
1. Ты можешь просто
git pull -rвместо этого.2. Если я буду работать
my-branch, будет ли это перебазироваться поверхorigin/masterилиorigin/my-branch? Первое — это то, чего я хочу.3. Если вы работаете в филиале, удаленный не должен опережать локальный, поэтому вам вообще не нужно будет тянуть. В этом случае я бы предложил подключить master, а затем перебазировать ветвь на вашем локальном мастере; в противном случае вы оставите master позади origin/master, что может привести к путанице позже.
4. Команды в моем ответе достигают этого. Без необходимости переключаться на мастера, а затем возвращаться в свою ветвь.
5. Я не говорил иначе. Однако, если вы используете master pull-r короче, и если вы этого не сделаете, это оставит локального мастера позади origin/master.