Вот как я использую Git на работе

1 болтовня

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

2 предисловия Git.

В повседневной работе по разработке неизбежно использование git для управления кодом, и умелое использование git позволит нам иметь更多的时间专注于代码编写, чтобы ускорить общую эффективность разработки. Однако для меня,git只是工具, достаточно некоторых рутинных операций, и вам будет интересно изучить его более подробно, когда вы будете свободны. Неважно, если вы не знакомы с git, просто изучите его. Если вы быстры, просто прочитайте несколько команд, а затем попрактикуйтесь в них самостоятельно, чтобы справиться с ежедневной разработкой.

3 общие команды Git

Я использую идею для работы с git в повседневной разработке. Конечно, в некоторых сценариях я также набираю команды в панели терминала идеи. Вы можете управлять им с помощью нескольких команд.井然有序.

3.1 Клонировать проект git clone

От удаленного проекта Kura к идее: VCS-> Checkout from Version Control-> Git, вставьте URL-адрес и нажмите «Клонировать», идея поможет нам выполнить команду git clone.

Конечно, вы также можетеgit clone https://gitee.com/xxx/Test.gitПосле локального импорта проекта в идею

3.2 Просмотр ветки git ветки

Проверьте, какие отделения имеют текущий проект

3.3 Код обнаружения git checkout

Получить код удаленного филиала

git checkout -b dev(本地分支名称) origin/dev(远程分支名称)

3.4 Создать ветку git checkout -b

Иногда вы хотите создать исполняемый файл ветки самостоятельноgit checkout -b dev(分支名)

Эквивалентно 2 командам

git branch dev

git checkout dev

Помните, обязательно создайте новую ветку на последней основной ветке.

3.5 Вытягивание/фиксация/пуш-код git pull/git commit/git push

Эти операции действительно最基本Да, я считаю, что среди всех команд, большинство людей знакомы с этим. Здесь я обычно работаю с помощью идеи.

Если несколько человек разрабатывают одну и ту же ветку, как правило, самый последний код должен быть извлечен перед отправкой, но кто может гарантировать, что даже после того, как вы выберете, в момент отправки кто-нибудь отправит код?

1. Если кто-то еще отправил код,idea会在你push时提示你要不要merge, если конфликта нет, то он будет автоматически слит, и в это время в логе git будет такая строчка

   Merge remote-tracking branch 'origin/dev' into dev

   ведение журнала git больше не будет полной строкой. Если есть конфликт, его нужно разрешить вручную.

2. Если вы вытащите первым, лучше всего, если конфликта не будет.Если есть конфликт, вы не сможете вытащить, что указывает на то, что локальная модификация будет перезаписана.

   • В это время вы можетеgit stash 暂存修改。

   • После успешной подготовки git pull извлекает код.

   • git unstash обновляет поэтапный код до текущей ветки.

Если в это время возникает конфликт, его можно разрешить вручную, а также Idea обеспечивает хорошую визуальную графику, что значительно упрощает решение конфликтов.

Локальный код слева, удаленный код справа, а код после среднего слияния успешно

3.6 Отменить операцию

1. Если вы хотите отказаться от изменения перед фиксацией, просто щелкните файл правой кнопкой мыши и выберите «Отменить».

2. После фиксации я еще не нажимал и хочу отменить операцию перед фиксацией.

   git reset --hard HEAD~ --hard восстанавливает предыдущую версию напрямую без сохранения изменений (используйте с осторожностью)

   git reset --soft HEAD~ --soft还原到上一版本，保留commit前的修改(常用)

   git reset --mixed HEAD~ --mixed отличается от soft тем, что восстанавливает файлы, которые не были временно сохранены до git add

   Графический GIt->Репозиторий->Сбросить HEAD...

HEAD~предыдущая версия

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

3. Я хочу откатиться после нажатия.

   Вышеупомянутая операция все еще может быть использована, но после следующего нажатия версия до отката будет объединена с текущей модификацией, и есть конфликты, которые необходимо разрешить.

3.7 Слияние кода git merge

Здесь я обычно работаю графически, сливая удаленный код с моей текущей веткой.

merge dev(分支名) into current

4 Многопользовательский кооперативный режим разработки

Так называемая модель сотрудничества в целях развития простоgit的分支管理.

Из-за разного объема бизнеса и разного количества серверов у каждой компании есть свои管理规范.

Проще может быть主干master,开发分支dev.

сложнее功能分支feature,bug修改分支fixbugИ даже测试分支test,预发布分支pre-release.

Конечно, названия и названия этих разных сценариев определяются сами собой, но каким бы простым ни был ваш проект,最好不要简化到只有master和dev分支.

Я как-то присоединился к компании, и когда я увидел, что в ней есть только мастер- и дев-проекты, я прямо сказал тогда разработчикам, что если вы это сделаете, то не столкнетесь ли вы с определенными проблемами? не ожидал Одним предложением, поэтому спецификация управления филиалом стандартизируется позже.

那会有什么问题？

• Мастер — это стабильная онлайн-ветка кода, которую, как правило, нельзя изменить напрямую.В настоящее время к продукту предъявляются два или более требований.因进度不同不能同时上线, 这时你们共用一个dev，那岂不是把别人未测试过的代码给上了? Вы можете сказать, что наша компания не имеет большого спроса, и мы только разрабатываем следующую функцию после запуска функции, тогда я хочу написать некоторые демо-тесты и оптимизации в частном порядке, или мне нужно изменить это на dev?

• Я хочу протестировать и запустить два функциональных требования вместе, поэтому я разрабатываю в dev? Лучше отделить и построить свою ветку разработки,避免其他同事在解决冲突时因不熟悉git把你的代码给干掉了. Вы можете объединить их вместе позже, когда захотите выйти в Интернет вместе.

Режим управления, который я сейчас использую,master+多个feature分支, и это все:

1. спрос вниз, вmaster上建个功能分支, Название F + Time + Имя функции, например: f_20200521_COUPON (определить a a one ownere).
2. Локальная разработка и серверное тестирование直接部署功能分支的代码.
3. Когда тест пройден и вот-вот появится в сети,checkout本地的master，git pull拉最新代码.
4. Снова切换回自己的功能分支A，并merge matser into current, разрешите конфликт вручную.
5. Если вы хотите выйти в интернет вместе с чужими ветками (определить пока B),最好先叫你的伙伴先合master代码, а затем повторите шаги 3 и 4, извлеките B, переключите A и объедините B.
6. существуетgitlab等私服申请请求合并，merge A into matser, не будет абсолютно никакого конфликта.
7. После слияния с мастером删除自己的功能分支.
8. Мастер развертывается на сервере и подключается к сети.

Шаг 3 Почему? На самом деле, для первых 4, шаг 6 службы, мы должны сначала убедиться, что ваш локальный матсер находится в сети последним, после шага 4 перейти к шагу 6, потому что мастер обновлен и на шаге 4 конфликт разрешен, к шагу 6 абсолютно не конфликтует.

Почему бы просто не объединить A с текущим (основным) после шага 3? Из соображений безопасности мастер, как правило, не может напрямую управляться локально и является защищенной ветвью.

Зачем сливать А в мацер на 6 шаге после слияния мацера в А на 4 шаге, обойди, ты издеваешься? На выше был дан ответ, мастер ветка вообще авторизована (защищена), мердж А в мацер нельзя оперировать локально, только на гитлабе (git private server), но гитлаб не может вручную разрешать конфликты, поэтому надо сначала слить матсер в А локально и разрешить конфликты вручную, а затем к шагу 6 можно отлично слиться.

У меня закружилась голова...???

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

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

5 рекомендаций

[Рекомендация 1] Обязательно создайте новую ветку на последнем мастере, иначе код не будет тестироваться другими, когда он находится в сети.

[Предложение 2] Отправьте код после выполнения функциональной точки, чтобы избежать потери кода, вызванной непредвиденными событиями. При разработке с другими в одной ветке делайте коммиты раньше, не разрешая конфликты. Оставьте это кому-то другому, хахаха.

[Предложение 3] Если вы не уверены, не будет ли он неправильно обработан при разрешении конфликтов, лучше всего перед этим подергать коллег, которые написали этот код, чтобы посмотреть его вместе.

[Предложение 4] Лучше всего уведомить группу разработчиков после онлайн-слияния с мастером, чтобы другие коллеги по разработке могли получить последний мастер-код и как можно скорее объединить его в свою собственную ветку.

[Предложение 5] В связи с предложением 4 Цикл развития длинный, а последний мастер онлайн должен быть объединен в филиал, в настоящее время в настоящее время в разработке во времени, чтобы избежать проведения времени разрешения большого количества конфликтов до окончательного запуска, И в то же время избегайте восходящего бизнеса, которое вы зависите от модификации как можно скорее. Поднимает новое исключение.

[Рекомендация 6] Неожиданный обзор кода.

【Предложение 7】不用提交本地文件或者一些带有个人配置的文件，如.idea文件夹里的文件。IP в конфигурационном файле желательно 127.0.0.1, чтобы каждый мог использовать его локально при отправке, а также пароли учетных записей различных мидлваров можно унифицировать.Если приходится использовать свою конфигурацию, то не стоит отправлять эти файлы в Git, иначе всегда будут конфликты, когда другие тянут проекты! ! !（强烈补充，深受其害）

6 Резюме

В этой статье представлены мои обычные команды git и некоторые рутинные операции, режим управления ветками, спецификации запуска проекта, ежедневные предложения по развитию и т. д. Это слишком просто, слишком сложно писать, просто запишите мою обычную работу и некоторые идеи.

Как новичок git, и даже не знал, что git не имеет большого значения, теперь узнайте достаточно.

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

Я хочу получить более полную ссылку доступнуюУчебник по git от учителя Ляо Сюэфэна

Я бы порекомендовал еще один, написанный иностранкойОтображение анимации команды git

Увидимся в следующий раз! ! ! !