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

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

Кто-то другой уже отправил коммит?

git pull --rebase

А почему rebase? merge не поможет разве?

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

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

Действительно.

Зачем делать мёрж, когда можно сохранить линейность ребейзом?

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

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

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

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

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

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

Зачем сохранять линейность ребейзом, если можно сделать мёрж?

Утро юродивых анончиков

git pull --rebase

Ага! И почаще... будет повод поболтать на ЛОРе о detached state...

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

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

При чём тут detached state?

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

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

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

Линейность разработки - ложь. merge как сказали.

Нелинейность разработки - ложь. rebase как сказали.

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

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

При чём тут detached state?

Да так, не при чём. Само как то получается.

https://www.google.com/search?client=ubuntu&channel=fs&q=git detached...

Само как то получается.

В каком случае?

google.com

?

google.com

В каком случае?

В google.com написано, что при неуспешном rebase HEAD остается detached.

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

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

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

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

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

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

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

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

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