LINUX.ORG.RU

git не могу понять конфликты

 


0

1

работаю только в мастере. сделал изменения, закомитил. пытаюсь запушить- пишет что нужно обновиться. делаю pull- пишет что есть конфликт.

как делать чтобы конфликтов не было? я файл менял в одном месте, другой человек просто дописал в конец новую функцию, а в итоге конфликт

Не работайте в одной ветке - не будет конфликтов. :) А чего вы хотели - один и тот же файл изменен двумя людьми, естественно система перестраховывается и предлагает разрешить конфликт.

strangeman ★★★★
()
Последнее исправление: strangeman (всего исправлений: 1)
Ответ на: комментарий от strangeman

когда я исправил файл, как дальше быть? он пишет на нем unmerged, появились новые файлы (наверно другой их запушил)

прийдется их заново комитить?

kommersant ★★
() автор топика
Ответ на: комментарий от kommersant

`git add файл` для сигнализирования о том, что конфликт в файле разрешен.

Потом делай коммит.

dmitry_malikov ★★
()
Ответ на: комментарий от kommersant

Поехали сначала:

Попытался запушить, гит ругнулся:

strangeman@strangepc:~/sources/1/puppet$ git push
To /home/strangeman/sources/puppet.git/
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '/home/strangeman/sources/puppet.git/'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.

Делаем git pull, как и посоветовал git:

strangeman@strangepc:~/sources/1/puppet$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/strangeman/sources/puppet
cf067ea..bbfd925 master -> origin/master
Auto-merging puppet.conf
CONFLICT (content): Merge conflict in puppet.conf
Automatic merge failed; fix conflicts and then commit the result.

Лезем в файлы, которые помечены как конфликтные, смотрим что гит там нарулил, правим если надо. Потом коммитим отмерженную версию

strangeman@strangepc:~/sources/1/puppet$ git commit -a
[master 0cfe31c] Merge branch 'master' of /home/strangeman/sources/puppet

Потом спокойно ее пушим. Все.

strangeman@strangepc:~/sources/1/puppet$ git push
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 618 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
To /home/strangeman/sources/puppet.git/
bbfd925..0cfe31c master -> master

В чем проблема-то?

strangeman ★★★★
()
Последнее исправление: strangeman (всего исправлений: 1)
Ответ на: комментарий от kommersant

прийдется их заново комитить?

Засташь их. Потом пулл и мёрдж со сташем.

unborn
()

http://git-scm.com/book/ru

Почему еще никто не отправил? Человек не врубается как git работет, без понимания смысла с ним работать мало.

s9gf4ult ★★
()

Использовать топик-бранчи и git rebase

annulen ★★★★★
()

Конфликты это нормальное развитие событий если правиться один и тот же функционал, от этого никуда не денешься. Всего то лишь нужно иметь на готове нормальный инструмент для разрешения конфликтов(под linux я юзаю meld).
Что бы удобно разрешить конфликты обычно достаточно бывает сделать git mergetool.
Если есть возможность, нужно сделать так что бы члены команды работали над разными частями задачи.
Я, и многие другие использовали например такую схему работы http://habrahabr.ru/post/106912/, при этом, если фичи не пересекаются конфликтов не возникает, плюс всегда имеем готовый к релизу мастер. На практике так бывает далеко не всегда, да и гит иногда тупит, там где можно было бы и смержить, но обычно,если это был разный функционал, хоть даже и в одном файле, конфликтов либо не бывает, либо они разрешаются очень просто и проще их просто ресолвить чем запариваться сделать так чтобы их избежать совсем.

З.Ы. В твоем случае - возможно конфликт возник из-за разных отступов, посмотри повнимательней различия, какой нить ui тулзой для мержа. Для того что бы избежать такого в дальнейшем - нужно прописать в code-style как должны быть устроены отступы и не мержить код, который не соответсвует code-style, ибо некоторые ide например автоматом правят tab на 4 пробела или наоборот.

batbko
()
Ответ на: комментарий от gv

Что такое неуспешный rebase? Это когда не осиливаешь порезолвить конфликты и не делаешь rebase --abort?

Допустим, что остаётся, а чем это плохо?

dmitry_malikov ★★
()
Ответ на: комментарий от dmitry_malikov

Это когда не осиливаешь порезолвить конфликты и не делаешь rebase --abort?

Просто когда есть конфликты.

Допустим, что остаётся, а чем это плохо?

Ну, кого-то это может сбивать с толку, поэтому позиция не делать rebase, чтобы не было лишнего геморроя, понятна.

gv
()
Ответ на: комментарий от dmitry_malikov

А резолвинг конфликтов при мёрже происходит не в детачед стэйте?

Нет, AFAIK merge никогда detached не делает. Кроме того можно делать merge с грязной рабочей копией, если merge не затрагивает незакомиченные изменения.

gv
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.