Работа с гит

Делишься опытом или что?

У гита есть официальный туториал. Прочитай его

У гита есть официальный туториал. Прочитай его

Читал, но где там нет об командной роботе

Я вообще с Mercurial (hg) работаю, но мне кажется это старший сотрудник должен всё это делать. Ты push-аешь в remote и никому не мешаешь в процессе работы. И вот когда ты спустя N коммитов доделал фичу, то более опытный/главный должен pull-ить на свой комп из вашего общего репозитория и мержить твою ветку с новой функцией в master сам. А может он из N веток хочет создать тестовую сборку? Ты представляешь что будет если ты такой красивый сам смержишь в мастер в большой команде?

Хотя я могу ошибаться, но мы в нашей недо-команде быдлокодеров каждый пашет в своей личной ветке, периодически вливая к себе наборы изменений от других или из основной ветки (считай мастер). А вот когда достигнуто некое состояние, уже кто-то один наконец сливает всё в основной ото всех.

Часть одного из трех основных вариантов организации совместной работы через git для случая двух разработчиков ты вроде уловил.

Так нас только двое, и оба примерно одинакового уровня.

man gitflow

man githubflow

В кратце - есть точка синхронизации: develop или master все вливания начинаются и заканчиваются в ней.

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

Кто последний решил запушить в точку синхронизации тот и, папа резолвит конфликты.

upd. man mergerequest

upd2. работать в команде(даже из двух человек) без мерж риквестов не очень удобно - поднимите себе хотя бы гитлаб

man vagrant || man docker ; man gitlab

Сомнительный способ. На одном репе гита разрабатывать это как работаь за одним компом с одного аккаунта. Можно конечно, если всего два человека и хорошо между собой договариваются. Но втроём будет уже очень сложно, а вчетвером так и просто ад начнётся.

Начните с простого: сначала возьмите себе одну ветку, назовите например dev, работайте в ней вместе.

• Докодил какую-то часть задачи, сделал git stash
• Получил изменения от второго через git pull
• Сделал git stash pop — тут вылезут все конфликты, которые нужно поправить.
• Закоммитил git commit -am "Hello"
• После этого со спокойной душой делать git push

Каждый раз создавать ветки, как описано в первом посте идеологически неправильно. Если говорить о ветках и более сложной организации, то можно так:

• Создал ветку через git checkout -b NAME && git branch --track
• Докодил какую-то часть задачи, сделал коммит (n раз)
• После того, как вся задача готова, переключаемся на dev, делаем git pull
• После этого мержим

язабан. еще один дeбильный тред забенного в гугле

man gitflow

с ещё одним человеком

git clone ...

git fetch origin
git merge origin/master
...
правим код
...
git fetch origin
get merge origin/master
...
правим конфликты
...
git push origin master

https://www.atlassian.com/git/tutorials/comparing-workflows

Рано тебе работать. Сначала научись читать.

В целом все верно.

Еще лучше, если вы поднимите gitLab. Тогда схема работы будет такой:

git clone
git checkout -b myBranch
//hard working
git push origin myBranch
//смотрим в веб интерфейсе, можно ли автоматом замержить в местер
//если есть конфликты, 
//    чекаутим мастер, 
//    мержим его в свой бранч,
//    разрешаем конфликты
//    пушим новое состояние myBranch
//кодревью
//в вебинтерфейсе мержим myBranch в master

а где здесь pull request?

gitflow:
master - то что содержит текущий релиз с которого ты собираешь релиз
dev - текущая нестабильная ветка
release/X.X - то что выделяют из dev и сливают в master когда дают отмашку на релиз
hotfix/X.X.X - то что содержит корректирующий выпуск и сливаятся в master когда дают отмашку на релиз корректирующего выпуска
(features|bugfix)/task-id - та в которую ты делаешь задачу в зависимости от типа и слоиваешь в dev|release|hotfix
epic/task-id - та от которой ты выделяешься для выполнения подзадач в рамках общей задачи, та в которую ты сливаешь доработки, та из которой ты подтягиваешь реактивные доработки других, после слияния всех подзадач в epic - epic сливается в dev|release|hotfix

и не забывай удалять ветки после слияния

//в вебинтерфейсе мержим myBranch в master

убиват за такое

и да, на master ставь тэги с релизом

Обоснуешь?

кодревью - это и есть пулреквест.

https://guides.github.com/introduction/flow/
Можешь не благодарить.

Ванильный гитфлоу для команды из двух человек, это то, за что надо убивать, а не за мержриквесты, прививающие ревью и собираемые ci :)

master - то что содержит текущий релиз с которого ты собираешь релиз

что тут непонятно? master это не то место куда надо сливать на каждый чих.

master - это текущая ветка разработки.

Для релизов заводятся отдельные ветки, в которых происходит стабилизация и куда «подливаются» исправления багов.