Как работать над одним проектом, если работаешь на 2 разных компах?

Question

[svilkov87]

Добрый день!
Я собираюсь работать над проектом, в котором используется git и gulp. Конечно же есть репозиторий на github.
Над этим проектом я буду работать в офисе, за одним компом с 15 00 до 18 00, а с 20 00 до полуночи - за другим компом.
За эти периоды времени сохранения и изменения будут отличаться.
Если конкретизировать вопрос, то нужна возможность как-то получать проект со всеми последними изменениями сделанные на предыдущем компе.

Перезаливать проект каждый раз с github?

Answer 1

[Дмитрий]

Доброй ночи.
Ну да, в 18:00 делаете фиксацию на github, а в 20:00 получаете новую версию с github и в полночь опять - фиксация на git.

P.S. Получается такая схема:
1) 15:00, включаете первый комп, выполняете git fetch origin
2) 18:00, выполняете git push origin имя_ветки, выключаете комп
3) 20:00, включаете второй комп, выполняете git fetch origin
4) 24:00, выполняете git push origin имя_ветки, выключаете комп

Comments

[svilkov87]

А перезаливать на комп лучше всего git pull?

[Дмитрий]

svilkov87: Вы делаете push того кода, надо которым Вы работали. Чтобы получить новую ревизию делаете fetch
Подробней здесь

[Everything_is_not_so_bad]

svilkov87: "git pull" - это операция синхронизации локальной ветки с последними изменениями на сервере репозитория
slo_nik : для "заливания" достаточно "git push".

[Sly_tom_cat .]

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

[Алексей Шумкин]

Sly_tom_cat .: "Здравствуй, жопа, Новый год!"...

[Sly_tom_cat .]

Алексей Шумкин: вы о чем?
У меня именно так синхронизируется несколько гитовых реп между рабочим и домашним компом (через тындекс диск). Очень удобно и никаких проблем ни разу не испытывал.

[Алексей Шумкин]

и никаких проблем ни разу не испытывал

Sly_tom_cat .: считаю это ошибкой выжившего )))
что будете делать, когда "испытаете" проблему? например, при аварии у вашего провайдера, когда тырнета не будет хотя бы сутки?

З.Ы. перед уходом домой/из дома хоть коммитите незавершённое? ))

[svilkov87]

Алексей Шумкин: ржунимагу))

[abberati]

мы встроим тебе облачное хранилище в систему контроля версий, чтобы ты не мог контролировать версии, пока контролируешь версии.

Sly_tom_cat .: git придумали специально для того, чтобы не использовать облачное хранилище.

[DevMan]

Алексей Шумкин: чем поможет git при отсутствии тырнета?
ответ - ничем. так что проблема совсем не в этом.

abberati: как, не странно, git придумали для контроля версий, а не "специально для того, чтобы не использовать облачное хранилище".

[Алексей Шумкин]

DevMan: JFIY git bundle

[DevMan]

Алексей Шумкин: еще есть и git archive.
что в общем то равно и простому созданию архива.

поинт понятен, но отсутствие интернета как аргумент ваще не катит.

[Алексей Шумкин]

DevMan: git bundle отличается от git archive так же, как VCS-репозиторий от tar/zip-архивов
Меседж был в этом

[DevMan]

Алексей Шумкин: меседж был в том, что контроль версий - это одно.
а простая синхронизация между различными компами - это другое.

бесмысленно упирать на то, что одно лучше другого, поскольку они решают разные задачи. особенно в плоскости "нет интернета".

[Sly_tom_cat .]

DevMan: +100500
Мне не понятен подход "git придумали специально для того, чтобы не использовать облачное хранилище."
Это примерно так же как говорить, что если у вас есть интернет, то вам не нужно пить и есть.

git и облака - это совершенно перпендикулярные вещи.

Коммитить незавершенное только потому, что надо переместиться от одного компа к другому - совершенно неверный подход. Зачем коммитить не завершенную работу, т.е. порой просто не работающий код.

По поводу перебоев со связью - они могут быть, но если вы привыкли к всегда доступному интернету, то не грех иметь дома резервный 4G модем на случай если бигпровайдер.ру вдруг отчибучит опять (когда был кляйн.провайдер.ру - годами перебоев не было, но модем в тумбочке все равно лежал). А на работе и так каналы резервированы.

Зы да, когда-то очень давно с работы домой путешествовали мои личные проектики и документы на флешке/переносном hdd. Сейчас это смешно вспоминать.

[Алексей Шумкин]

Коммитить незавершенное только потому, что надо переместиться от одного компа к другому - совершенно неверный подход. Зачем коммитить не завершенную работу, т.е. порой просто не работающий код.

это в Вас говорит подход централизованных VCS, где "ой, боюсь закоммить, т.к. что-нибудь сломаю"

в Git царит концепция "commit often", т.к. то, что было однажды закоммичено - потерять сложно
а отдельные ветки избавляют от страха коммитить нерабочий код, т.к. это, собственно, ОТДЕЛЬНЫЕ ветки...

[Алексей Шумкин]

DevMan:

бесмысленно упирать на то, что одно лучше другого, поскольку они решают разные задачи. особенно в плоскости "нет интернета".

особенно в контексте поставленного ТС вопроса, ага!

[DevMan]

Алексей Шумкин: тащемта, в контексте этого комента Как работать над одним проектом, если работаешь на 2 разных компах?

[abberati]

Sly_tom_cat .: а в чём проблема коммитов с неработающим кодом?

Тащемта, пример: есть Вася и Петя. Вася работает с фронтом, Петя - с бэком. Допустим, Вася устал и ушёл с работы, не закончив таску. Закоммитил накоженное в свою ветку, о которой Петя может даже и не знать. Вася пришёл домой, перекусил, отдохнул, взял последнюю версию из своей ветки и обнаружил: ба, да оно же такое же, каким я его оставил! Не дела, надо дописывать. Дописал, запушил в общую ветку develop.

Собственно вопрос: ЗАЧЕМ нужно облачное хранилище при работе с репозиторием? Репозиторий также является (из определения) хранилищем, но с более строгой структурой и с большим числом плюшек.

[Sly_tom_cat .]

abberati: Ну хотите коммитить/пушить плохой код - коммитте/пуште на здоровье.

Только вот вы в упор не понимаете, что GIT версионность кода призван контролировать, а не организацию хранения локального репозитория.

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

[abberati]

Sly_tom_cat .: как связаны нерабочий код, центральный репозиторий и моветон?

Ветки! Если вся разработка ведётся в одной ветке, то любой пуш будет моветоном. Рабочий/нерабочий код - не важно. Если перед слиянием веток не происходит code-review, всё может рухнуть в любую секунду.

Нагораживать облачное хранилище над репозиторием избыточно. Вот и всё.

[Sly_tom_cat .]

abberati: ну вам избыточно вы и пуште при уходе с работы и из дома, а я просто встаю из за компа и перемещаюсь за другой, а пушу по делу, а не из за такой чисто технической вещи как смена рабочего места.

[abberati]

Sly_tom_cat .: я и в процессе работы коммиты делаю. Грамотно написанный комментарий и коммит раз в один-два часа позволяют не расстраиваться при откатах.

[Sly_tom_cat .]

abberati: пушите тоже каждый час?

[abberati]

Sly_tom_cat .: а вы знаете, что происходит при пуше локальной ветки, если в ней есть несколько новых коммитов?

Ответ: то же самое, как если бы вы пушили после каждого коммита.
Ответ на ваш вопрос: нет, пушу по необходимости.

[Sly_tom_cat .]

abberati: спасибо кэп.
Только ваша необходимость дополняется пушами при смене места опоры вашей пятой точки. ;)

[abberati]

Sly_tom_cat .: точно! О боже мой, я же в нажимаю лишние четыре клавиши в консоли! Я был неправ. Теперь я понял.

Answer 2

[Евгений]

нужна возможность как-то получать проект со всеми последними изменениями сделанные на предыдущем компе.

А разве не для этого нужен гит?

Comments

[Евгений]

Дмитрий Кирилин: я бы не был столь категоричен. Да, не спорю, есть некоторые минусы, но все не так уж и плохо

Answer 3

[tvelforce]

git add. / git push не?