скоро начну работать в новой команде над проектом, там используется Git (вроде Gitlab)
стыдно, но никогда серьезно и в команде не работал с Git. Использовал его (github) в одиночку и в режиме SVN (т.е. пушил сразу в мастер)
Думаю надо подготовиться, что бы не ударить в грязь лицом: с чего начать лучше?
может завести репозиторий на том же гитхабе и создавать/мержить ветки?
попытаться понять разницу между merge и rebase?
что еще важно?
По веткам как обычно принято: заводят ветку на каждую, даже мелкую, задачу и потом делают мерж?
Здравствуйте, Quadri, Вы писали:
Q>Думаю надо подготовиться, что бы не ударить в грязь лицом: с чего начать лучше? Q>что еще важно?
А это разве зависит не от правил проекта? Если правил нет, то можно делать как угодно. Если они есть, то просто следовать правилам. Я не сомневаюсь, что у нового программиста хватит умений делать хоть по сто новых веток в сутки и извращаться с гитом как только ему захочется. Писать свои "смишные" комментарии для коммитов. В общем свою мысль я уже высказал. Единственное что, если явно прописанных правил нет, можно посмотреть на репозиторий проекта, и попытаться следовать негласным правилам, то есть догадаться как принято, даже если там всё сделано от балды и на халяву.
Здравствуйте, Quadri, Вы писали:
Q>скоро начну работать в новой команде над проектом, там используется Git (вроде Gitlab) Q>стыдно, но никогда серьезно и в команде не работал с Git. Использовал его (github) в одиночку и в режиме SVN (т.е. пушил сразу в мастер) Q>Думаю надо подготовиться, что бы не ударить в грязь лицом: с чего начать лучше? Q>может завести репозиторий на том же гитхабе и создавать/мержить ветки?
ИМХО, это первая проблему которую необходимо решить. Нужно понять что никакой github
и вообще сторонний сервис не нужен для экспериментов.
Q>попытаться понять разницу между merge и rebase? Q>что еще важно? Q>По веткам как обычно принято: заводят ветку на каждую, даже мелкую, задачу и потом делают мерж?
Ну если уже умеете делать коммиты и потом их пушить. То нужно почитать про разные стратегии
merge и про их использование в merge/rebase. И научиться редактировать историю.
То есть создать пару файлов в master, сделать новую ветку, сделать там 4 коммита,
а потом выбросить один, объединить два других, а третий в середине чуть-чуть подправить.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, Quadri, Вы писали:
Q>>Думаю надо подготовиться, что бы не ударить в грязь лицом: с чего начать лучше? Q>>что еще важно?
V>А это разве зависит не от правил проекта? Если правил нет, то можно делать как угодно. Если они есть, то просто следовать правилам.
Я не знаю, мне вот и хотелось бы услышать в ответ типа "у нас примерно так и так с ветками/мержами (кратко)" или "мире гит только так и так и иначе никак" что бы получить представление как оно бывает и потом суметь сориентироваться/задать нужные вопросы и т.д.
Здравствуйте, Zhendos, Вы писали:
Z>ИМХО, это первая проблему которую необходимо решить. Нужно понять что никакой github Z>и вообще сторонний сервис не нужен для экспериментов.
точно, я забыл что можно без сервера все делать
Z>Ну если уже умеет делать коммиты и потом их пушить. То нужно почитать про разные стратегии Z>merge и про их использование в merge/rebase. И научиться редактировать историю. Z>То есть создать пару файлов в master, сделать новую ветку, сделать там 4 коммита, Z>а потом выбросить один, объединить два других, а третий в середине чуть-чуть подправить.
Здравствуйте, Quadri, Вы писали:
Q>может завести репозиторий на том же гитхабе и создавать/мержить ветки?
С ветками можно поиграться и локально. Но завести репу на гитхабе стоит чтобы освоить интерфейс, посмотреть как работать с pull request, делать замечания к нему, сравнивать ветки, навигация по коду и пр.
Q>попытаться понять разницу между merge и rebase?
Да.
Q>что еще важно?
История, blame, поиск по автору, найти удаленный код.
Правила что есть комитом. Каждый чих записывать отдельно или всю задачу в конце склеивать (fixup, squash).
stash может пригодится.
Q>По веткам как обычно принято: заводят ветку на каждую, даже мелкую, задачу и потом делают мерж?
В общем да. Но нет единого правила от команды к команде. Можно мелкие и в одну ветку объединить, а бывает и что одну задачу нельзя выкатить сразу и делается несколько веток.
Здравствуйте, msorc, Вы писали:
M>Здравствуйте, Quadri, Вы писали:
Q>>может завести репозиторий на том же гитхабе и создавать/мержить ветки? M>С ветками можно поиграться и локально. Но завести репу на гитхабе стоит чтобы освоить интерфейс, посмотреть как работать с pull request, делать замечания к нему, сравнивать ветки, навигация по коду и пр.
Тупые вопросы продолжаются: я всегда думал что pull request это штука когда я предлагаю коммит в _чужой_ репозиторий и используется в open source, т.е. при обычной разработке внутри компании не используется, так?
Q>Тупые вопросы продолжаются: я всегда думал что pull request это штука когда я предлагаю коммит в _чужой_ репозиторий и используется в open source, т.е. при обычной разработке внутри компании не используется, так?
Ну обычно есть основная ветка продукта — master, может называться и по другому, dev, неважно. Вот ты закончил работу над задачей, делаешь pull request из своей ветки в основную. Тебе там коллеги говорят, где ты наговнячил, одобряют твои старания. Тесты могут на CI автоматом запускаться при открытии PR, например. Получил достаточное количество одобрений, выполнил требования — смержил.
Или даже допустим с коллегой разбили большую задачу на части, можно твою часть через PR в его ветку смержить.
Q>Я не знаю, мне вот и хотелось бы услышать в ответ типа "у нас примерно так и так с ветками/мержами (кратко)" или "мире гит только так и так и иначе никак" что бы получить представление как оно бывает и потом суметь сориентироваться/задать нужные вопросы и т.д.
Здравствуйте, Quadri, Вы писали:
Q>По веткам как обычно принято: заводят ветку на каждую, даже мелкую, задачу и потом делают мерж?
Мне тут чтобы добавить строчку в мой скромный опенсорсный проект, некоторые корреспонденты на местах делают форк моего репозитория, потом в своем форке делают бранч, в нем добавляют строчку, и делают pull request.
Зачем, я не понимаю. Могли бы и просто попросить нужную строчку добавить.
Можно почитать про gitflow, выбрать статью, которая зайдет, на русском или английском. Если его поймете, то неважно будет даже если на новом месте процесс отличается, по идее они эти отличия должны всем нвым программистам объяснять, даже если у них большой опыт с git. Gitflow — это, типа, идеальный процесс разработки при помощи git (не для холивара, многие не согласятся с идеальностью, но если человек понимает gitflow — то с git он работать может).
Здравствуйте, Pzz, Вы писали:
Q>>По веткам как обычно принято: заводят ветку на каждую, даже мелкую, задачу и потом делают мерж?
Pzz>Мне тут чтобы добавить строчку в мой скромный опенсорсный проект, некоторые корреспонденты на местах делают форк моего репозитория, потом в своем форке делают бранч, в нем добавляют строчку, и делают pull request.
Pzz>Зачем, я не понимаю. Могли бы и просто попросить нужную строчку добавить.
1. Это дёшево (github объединяет хранение форков).
2. Это удобно — сделал копию, проверил, обдумал со всех сторон, и тогда предлагаешь принять.
Здравствуйте, netch80, Вы писали:
N>1. Это дёшево (github объединяет хранение форков). N>2. Это удобно — сделал копию, проверил, обдумал со всех сторон, и тогда предлагаешь принять.
Зачем делать бранч внутри форка с чужого репозитория? Форк — сам по себе бранч.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
N>>1. Это дёшево (github объединяет хранение форков). N>>2. Это удобно — сделал копию, проверил, обдумал со всех сторон, и тогда предлагаешь принять.
Pzz>Зачем делать бранч внутри форка с чужого репозитория? Форк — сам по себе бранч.
А если нужно будет несколько изменений предложить ?
Проще заранее открыть ветку и не париться.
К тому же тот же GitHub делает это автоматически когда редактируется файл напрямую в веб странице.
Здравствуйте, Quadri, Вы писали:
Q>может завести репозиторий на том же гитхабе и создавать/мержить ветки?
пул реквесты через UI создаётся, там всё просто. Q>попытаться понять разницу между merge и rebase?
да. rebase предпочтительнее. смотри разные версии ребейза, мёржа, узнай что такой сквош, зачем нужен git push --force после ребейза. с мержом смотри что такой 3-вей мёрж, флаги thier, mine. разберись как конфигурировать через git config. Q>что еще важно?
черри-пик, стэш, лог, блейм. возможно сабмодули если они у вас будут. Q>По веткам как обычно принято: заводят ветку на каждую, даже мелкую, задачу и потом делают мерж?
примерно так.
Здравствуйте, Pzz, Вы писали:
Pzz>Зачем делать бранч внутри форка с чужого репозитория? Форк — сам по себе бранч.
Сохранение/передача дополнительной семантики в названии ветки.
