Максим Дьяченко

Либо на ЛОРе вам сказали неверно либо Вы неверно поняли.
git checkout — MyFile откатит конкретный файл к состоянию последнего коммита. Чудес не бывает и гит не знает что именно вы поленились закоммитить.
Как правильно сказали — или отказывайтесь к последнему коммиту и пишите заново, по памяти, или ищите способы восстановить данные средством системы или утилит восстановления. Но гит к этому отношения не имеет.

Полагаю что у тебя (или точнее как я понимаю у Димы?) гит пытается писать в изначальный репозиторий исходя из текущего положения.
Т.е. мы находимся непонятно где, а репозиторий у нас на Це. Пытаемся построить к нему путь, но поскольку родная среда это линукс то у нас это не выходит.

Давай определимся с задачей.
Если я правильно понял, то задача в синхронизации репозитория разработчика с продакшеном на сетевом диске?
Если так, то нужно делать ДВА репозитория и синхронизировать их через пулл/пуш.

Если я неверно понял задачу, то можно подробнее?

Обычная стратегия это: «одна фича — одна ветка». Ну или группировать их осмысленными блоками, которые деплоятся одновременно.

Другая распространенная стратегия это «редкие деплои». Т.е. мы пишем все в ветку дев, или в несколько. Мержим по необходимости, тестируем и т.п. а скажем раз в неделю сливаем все это в мастер, мигрируем базу и т.п. Если история коммитов ведется более-менее аккуратно, при необходимости подчищается на локальном репозитории, то ситуаций когда нужно отложить что-то в середине почти не бывает. А мелочи можно и подправить стандартными средствами.

Вот здесь есть немного по переупорядывачиванию коммитов. Может что-то придумаете более удобное для Вас.
git-scm.com/book/ru/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D0%B5%D1%80%D0%B5%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8

Управление историей. Нетбинс любит терять историю, реально рассчитывать на нее нет смысла. А тут это основа.
Ветвление и слияние. Когда нужно делать большое изменение, а система уже в продакшене, и ты вынужден ее поддерживать, то сделать ветку, и править на ней, а потом объединить ветки, да так чтобы не затереть изменения в обеих — почти невозможно когда нет системы управления версиями.
Совместная работа. Пропадает всякий бред типа в аське писать мол не трогай такой-то файл, я его правлю…
Сотни мелких коммитов с описаниями. Т.е. делаешь изменения, и сразу описываешь, и сразу видно в каких файлах это было и когда… Помогает в расследованиях, в документировании.
Возможность контролировать «что изменилось». Анекдотичный случай — я как-то в четыре часа ночи решил переименовать в одном классе модели поле desc на _text. Оно фигурировала в нескольких сотнях классов, поэтому я использовал поиск и замену. Полуручную.

Через месяц у меня выплыл глюк с сортировкой данных. Оказывается при поиске я случайно заменил desc в запросах в ORM. Был бы тогда GIT да получше покрытие тестами — не пришлось бы два часа искать причину. Я бы увидел, что у меня есть изменение в таком-то файле, а оно там неуместно…

Причин много может быть. Но возможно просто ваши объемы сложности еще не требуют от вас таких решений.