Подскажите, подойдет ли git для решения такой задачи

Ровно обратное это какое? Какая правильная политика? и как вы понимаете, что это неправильная?

Каждая строчка кода может быть отредактировна когда угодно и кем угодно, разработчики ни в коем случае не должны «договариваться» или ждать друг-друга (это особенно понятно, когда разработчиков много или они раскиданы по планете или один из них решит «заболеть» с «заблокированным» участком кода). Когда возникает конфликт правок, система контроля версий сообщает об этом и только тогда принимается решение, как этот конфликт разрешить. Даже если два человека редактируют один и тот же файл, конфликта у них не возникнет, пока они редактируют разные строки.

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

Чем чаще пушите коммиты, тем мельче масштаб конфликтов.

В git принято отгружать не отлаженные/непроверенные изменения?

Для этого придуманы ветки. Подумайте, что вы будете делать, когда вы выходите из офиса и хотите дописать код дома. Конечно же вы отправите его в репозиторий. Степень готовности кода не имеет значения, чем чаще отправляете в репозиторий, тем лучше. А вот сливание своих веток в ветку stable (или с названием версии) — это уже, конечно, когда всё отлажено и проверено.

Это выглядит красиво, отдельная ветка. Но ведь конфликт возникнет, когда тот разработчик, который закончил вторым попытается влить свой вылизанный код в вылизанный код того, кто редактировал первым. Т.е. масштаб конфликта будет не связан с частотой отгрузок

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

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

Я бы еще добавил что Merge можно делать в отдельную ветку, идентичную Master, решить все конфликты, проверить работоспособность, и потом спокойно все слить обратно в Мастер без конфликтов.

На хабре есть хорошая статья про rebase. При предложенной в ней подходе кол-во конфликтов будет меньше.

Вроде бы гит не позволяет пушить если локальная ветка не синхронизирована с удаленной, те перед пушем все равно нужно сделать rebase или merge если могут быть кофликты. Те поулчается так: Петя делает свою крутую фичу, пытается запушить, а ему в ответ «Петя, у тебя не последняя версия, обновить». Петя обновляется и ему говорит «Тут Вася делел фичу, она здесь и здесь пересекается с твоей фичей». Петя смотрит, разрешает конфликт и пушит.

Я так понимаю Вас пугает слово конфликт, и это будет адом если обновления и пуши будут происходить раз в неделю или больше (и это не зависит от системы конроля версий). Но уверен Вы не заметите конфликты если обновления и пуши будут делать хотя бы раз в день (все зависит от команды и интенсивности конечно). Понятно, что не каждую фичу можно сделать за день, но если вы будете придерживаться правила «одна фича — отдельная ветка» и ребейситься почаще, то никаких проблем у Вас не будет.

Я не работал с VSS, но однажды пришлось поработать с ClearCase, там была та же модель check in/check out. Как по мне для кода эта модель ужасна, для документов (не текстовых) она будет хороша, но для кода имхо нет. Если чекинить нужно модуль целиком, то видимо гит Вам не очень походит. А так гит отличная система контроля версий, некоторые даже скажут что лучшая.

Работа с гитом мне напоминает работу в google docs, а check in/check out больше как пересылка документа по почте или работу в sharepoint. Для одного пользователся это не важно, но если пользователей несколько, то скорость работы будет явно за google docs и чем больше людей будут одновременно работать, тем сильнее это будет сказываться.

Всем большое спасибо за ответы!

Т.е. ответ «нет, в git так нельзя»?
Это нормальная ситуация, когда надо блокировать целый модуль (группу файлов). Модуль это не только исходники, это и ресурсы и шаблоны, так часто случается, что блокировать надо целый модуль. Мы не испытываем никаких проблем при таком подходе, который сейчас есть, поэтому мне непонятны ваши утверждения о том, что у нас что-то не правильно. Не могли бы вы пояснить, что конкретно вы имеете ввиду в своем утверждении, может нам правда надо что-то поменять? Пока не вижу

Просто говорят — плохой вариант. Разработчик — человек, при этом работает с несколькими проектами одновременно. Может просто забыть что-то отгрузить, до тех пор, пока не получит звонок

Я не знаю полностью ваш процесс, поэтому конкретный совет вам дать не могу. Из своего опыта могу сказать, что даже в проекте с несколькими миллионами строк и десятками разработчиков *конфликты* — очень редкая ситуация. (И это не тот случай, когда определённый файл может править только один человек — владение кодом общее.) Именно поэтому я считаю что у вас что-то не так, если вы испытываете необходимость в блокировании для избежания конфликтов.

Разработчик может работать на многих проектах — если их настолько много, что он может и *забыть* что где и как, то это *проблема*.

>>Разработчик — человек, при этом работает с несколькими проектами одновременно
Тем более, работал с VSS много лет назад, было весело вылавливать человека с отпуска или болезни чтобы он расчекинил файлик. Инструменты должны помогать, а не мешать. Ну забыл, сделает ребейс, поправит конфликты если будут и смержите. У нас больше сотни человек над одним проектом трудились, а пулл реквесты, особенно в ядро месяцами не мержились и ничего, когда подходила очередь всё смерживалось без особого гемора.

p.s. Из agile: Люди и взаимодействия важнее, чем процессы и инструменты; Так что gribozavr прав, у вас проблема в этом месте

AmdY,
у нас нет проблемы вылавливать человека с отпуска/болезни, у нас есть специальный человек (точнее 2), которые могут разлочить исходники в экстренном случае. Пока считаю VSS подходит больше, т.к. мысль о том, что время от времени придется разрешать конфликты мне не нравится

Если люди у вас работают над одним кодом, то вам в любом случае придётся конфликты. В случае с гитом, он в большинстве случаев всё смержит сам. В случае с локами, кому-то либо придтся ждать, либо реп разлочится, правки внесутся, а затем появится со своими праваками чел, который лочил файл. Вам в таком случае придётся решать два конфликта — вручную мержить правки, проведывать в больнице чувака который разлочил файл и доставил эротическое удовольствие ручного мержа челу, который справедливо ожидал что файл никто не тронет.

AmdY,
если человек попадает в больницу/уходит в отпуск с залоченным файлом, то если он может говорить — сам примет примет решение, стоит ли отгружать код в таком состоянии, как сейчас, чтобы с ним могли работать другие или просто разлочить исходник без отгрузки. Если не может, то решение примут без него. Это форс-мажорный случай, и больше никаких конфликтов не возникает, работаем так уже давно. А то, что вы описали, употребив слово «эротическое» git-пользователь может испытать при любой отгрузке своего исходника