Ошибки новичка в Git, которых следует избегать
Простые вещи, которые нужно сделать, чтобы уберечь себя от разочарования и траты времени при использовании Git
Инженеры по обработке данных обычно лучше знакомы с такими инструментами разработки, как Git, чем аналитики данных, специалисты по данным и инженеры машинного обучения. За последние пару лет, поскольку все больше и больше не инженерных работ связано с написанием кода, системы управления исходным кодом, такие как Git, стали популярнее. Несмотря на то, что число пользователей растет, не все новички хорошо с этим справляются.
Команды, не являющиеся инженерами, часто сталкиваются с проблемами при использовании Git, когда работодатель не уделяет достаточно внимания обучению их команды или когда они не получают достаточной поддержки от своего коллеги-инженера. Модель каждый сам по себе неустойчива. Обучение - очень важная часть развития и роста команды.
Когда дело доходит до написания кода, у команд, не являющихся инженерами, другое мышление. Я попытался обобщить идеи в другой статье. Здесь мы поговорим не об ошибках, которые вы можете сделать, запустив неправильную команду Git, а о более фундаментальных ошибках, таких как работа непосредственно с основной веткой, выполнение очень крупных коммитов и т. Д.
Когда мастер - твоя единственная ветка
Вы по сути упустили всю концепцию Git (или систем управления версиями в целом), если вы являетесь частью команды и единственная ветвь, которая у вас есть, - это master. В этом случае у каждого есть локальная главная ветвь, и они фиксируются в этой ветке, а затем отправляют изменения удаленному мастеру, чтобы обнаружить, что существует миллион конфликтов. Избегайте этого, используйте ветвление - вот в чем самое интересное.
В Knittl на StackOverflow есть отличный обзор причин, по которым не следует использовать основную ветку для разработки.
главная ветвь должна представлять «стабильную» историю вашего кода. используйте ветки, чтобы экспериментировать с новыми функциями, внедрять их, а когда они станут достаточно зрелыми, вы сможете снова объединить их в мастер.
таким образом код в master почти всегда будет компилироваться без проблем и в основном может использоваться непосредственно для выпусков.
Несоблюдение методологии ветвления
Как только вы поймете основную концепцию ветвей и сможете создавать ветки и объединять их в мастер, следующая проблема, с которой вы столкнетесь, будет больше с точки зрения управления ветвями. Самая популярная и ценная из всех методологий ветвления - это gitflow. Я написал об этом здесь с точки зрения инженера по данным. Те же принципы применимы ко всем, чья работа связана с написанием запросов на SQL или чем-то подобным, например, скриптами Python с использованием pandas, numpy, scipy и так далее.
Gitflow включает три уровня ветвления с master, develop и feature в качестве трех разных уровней. Из этих трех есть исключения, но вам не нужно вдаваться в подробности вначале. Об этом подробнее здесь -
Фиксация тысячи файлов за одну фиксацию
Технически это не ошибка, это просто очень плохая практика. Помимо первоначального коммита в вашем репо, ваши коммиты должны содержать только те изменения, которые могут быть четко определены в однострочном сообщении о фиксации. Фиксация всех незафиксированных изменений не может быть хорошим сообщением о фиксации тысячи новых файлов.
Делайте небольшие, делайте часто.
Следуй этому правилу, и все будет в порядке. Идея состоит в том, чтобы продвинуть наименьшую полную единицу работы. Есть отличная статья, в которой подробно рассказывается об этом.
Вот еще пара замечательных статей, которые мне понравились, и я нашел нас
"Заключение"
Как и другие широко распространенные технологии, такие как SQL, Python, Javascript, Git - это то, без чего вы, вероятно, не сможете обойтись, если вы имеете какое-либо отношение к написанию кода - в любом качестве. Вам обязательно придется иметь дело с системами контроля версий. Следовательно, лучше всего потратить некоторое время на то, чтобы понять, что это такое и как работает.
Скорее всего, вам изначально не понадобятся более причудливые и хитрые команды Git, так как вы справитесь только с базовыми. Есть несколько статей, подобных этой, в которых рассказывается об ошибке, которую вы делаете, выполняя неправильные команды Git. Просто просмотрите некоторые из этих статей (1, 2, 3, 4, 5), и вас следует отсортировать.
