Git для користувачів Perforce

Я використовую Perforce протягом ряду років. Я хотів би перейти на використання git для мого особистого коду, але всі підручники з git, які я бачив, припускають, що ви є повноцінним контролем джерела n00b (що робить їх неймовірно нудними), або що ви звикли svn (яким я не є).

Я знаю p4, і я також розумію ідею розподіленої системи управління джерелом (тому мені не потрібен крок продажів, дякую). Що б я хотів, це таблиця перекладу з команди p4 на еквівалентні команди git, а також команди "не можу жити без", які не мають еквівалента p4.

Оскільки я підозрюю, що кожен користувач p4 використовує різні підмножини p4, ось кілька речей, які я регулярно роблю в p4, які я хотів би мати можливість робити у git, що не одразу видно з документів, які я розглядав :

1. створити декілька очікуваних списків змін в одному клієнті. ( p4 change)
2. редагувати список змін, що очікує на розгляд. (також p4 change)
3. перегляньте список усіх моїх очікуваних списків змін ( p4 changes -s pending)
4. список усіх змінених файлів у моєму клієнті ( p4 opened) або в списку змін, що очікує на розгляд ( p4 describe)
5. побачити різницю очікуваного списку змін (для цього я використовую сценарій обгортки, який використовує p4 diffі p4 describe)
6. для даного файлу подивіться, які надіслані списки змін вплинули на які рядки ( p4 annotate)
7. для даного файлу див. перелік описів списків змін, що вплинули на файл ( p4 log)
8. подати список змін, що очікує на розгляд ( p4 submit -c)
9. скасувати очікуваний список змін ( p4 revert)

Багато з них обертаються навколо "списків змін". "список змін" - це термінологія p4. Що таке еквівалентний термін git?

Здається, гілки можуть бути тим, що користувачі git використовують замість того, що p4 називає списками змін. Трохи заплутано, оскільки p4 також має щось, що називається гілкою, хоча, здається, це лише неясно пов'язані поняття. (Хоча я завжди думав, що концепція p4 філії є досить дивною, вона все ж відрізняється від класичної концепції RCS гілки.)

У будь-якому випадку ... Я не впевнений, як виконати те, що я зазвичай роблю в списках змін p4 з гілками git. У p4 я можу зробити щось подібне:

$ p4 edit a.txt
$ p4 change a.txt
Change 12345 created.

На даний момент у мене є список змін, який містить a.txt. Я можу редагувати опис і продовжувати працювати, не подаючи список змін. Крім того, якщо виявиться, що мені потрібно внести деякі зміни в деякі інші файли, наприклад, скажімо, виправлення помилки в якомусь іншому рівні коду, я можу зробити це в тому ж клієнті:

$ p4 edit z.txt
$ p4 change z.txt
Change 12346 created.

Зараз у мене є два окремі списки змін в одному клієнті. Я можу працювати над ними одночасно, і мені не потрібно нічого робити, щоб "перемикатися між ними". Коли настає час фіксації, я можу подати їх окремо:

$ p4 submit -c 12346  # this will submit the changes to z.txt
$ p4 submit -c 12345  # this will submit the changes to a.txt

Я не можу зрозуміти, як відтворити це в git. З моїх експериментів не видно, що git addпов'язано з поточною гілкою. Наскільки я можу зрозуміти, коли я git commitзбираюся зафіксувати всі файли, які я git addмав, незалежно від того, в якій гілці я був у той час:

$ git init
Initialized empty Git repository in /home/laurence/git-playground/.git/
$ ls
a.txt  w.txt  z.txt
$ git add -A .
$ git commit
 Initial commit.
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 a.txt
 create mode 100644 w.txt
 create mode 100644 z.txt
$ vi a.txt z.txt 
2 files to edit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   a.txt
#   modified:   z.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git branch aardvark
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git add a.txt 
$ git checkout master
M   a.txt
M   z.txt
Switched to branch 'master'
$ git branch zebra
$ git checkout zebra
M   a.txt
M   z.txt
Switched to branch 'zebra'
$ git add z.txt 
$ git status
# On branch zebra
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt
#
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git status
# On branch aardvark
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt

У цьому прикладі гілки aardvark та zebra, здається, містять абсолютно однаковий набір змін, і на основі результату git statusцього видається, що виконання коміту в будь-якому з них матиме однаковий ефект. Я щось роблю не так?

Я багато не використовував perforce, тому це може бути не зовсім переклад 1: 1. Потім знову розподілені системи керування джерелами, такі як git та mercurial, мають інакший робочий процес, тому перекладу у форматі 1: 1 насправді не існує (і не повинно бути). У будь-якому випадку, тут йдеться:

• Створіть кілька списків змін, що очікують на розгляд -> Натомість використовуйте гілки. У git гілки легкі та швидкі, для створення потрібно менше секунди, а для злиття зазвичай менше двох секунд. Не бійтеся часто розгалужуватися і перебазовувати.

  git branch new-branch-name
  git checkout new-branch-name
  

  Або зробіть все в одному рядку:

  git checkout -b new-branch-name
  

• Перегляньте список усіх очікуваних списків змін -> Оскільки еквівалентом декількох очікуваних списків змін є декілька гілок, просто перегляньте гілки:

  git branch
  

  Якщо ви хочете також переглянути віддалені гілки:

  git branch -a
  

  Вважається гарною практикою негайно видаляти гілку після успішного об’єднання, щоб вам не потрібно було відстежувати, яка гілка очікує на об’єднання, а яка вже об’єднана.

• Список усіх змінених файлів -> Для одного очікуваного "списку змін" у певній гілці git має поняття індексу або кешу. Для того, щоб здійснити зміну, спочатку потрібно додати файли до цього індексу. Це дозволяє вручну вибрати групу файлів, яка представляє одну зміну, або ігнорувати нерелевантні файли. Щоб побачити стан додавання файлів чи ні до цього індексу, просто виконайте такі дії:

  git status
  

• Дивіться різницю очікуваного списку змін -> Є дві частини цього. Спочатку побачимо різницю між робочим каталогом та індексом:

  git diff
  

  Але якщо ви хочете знати різницю між тим, що ви вводите зараз, і останнім комітом, ви справді просите різницю між робочим каталогом + індексом та HEAD:

  git diff HEAD
  

• Для даного файлу подивіться, які надіслані списки змін вплинули на які рядки -> Це легко:

  git blame filename
  

  або навіть краще, якщо ви перебуваєте у віконному середовищі:

  git gui blame filename
  

  Git gui займає більше часу для синтаксичного аналізу файлу (він був написаний в tcl замість C), але він має безліч чудових функцій, включаючи можливість "подорожі в часі" назад у минуле, натиснувши ідентифікатор коміту. Мені тільки хотілося б, щоб вони застосували функцію "подорожі в часі" в майбутнє, щоб я міг дізнатись, як нарешті буде вирішено дану помилку ;-)

• Для даного файлу дивіться перелік описів списків змін, які вплинули на файл -> також легко:

  git log filename
  

  Але git log - це набагато потужніший інструмент, ніж просто цей. Насправді більшість моїх особистих скриптів не використовує журнал git для читання сховища. Прочитайте сторінку керівництва.

• Надішліть список змін, що очікує на розгляд -> Також легко:

  git commit
  

Перегляньте мою відповідь на попереднє запитання, щоб побачити мій типовий робочий процес git: Learning Git. Потрібно знати, чи я на правильному шляху

Якщо ви будете слідувати робочому циклу, який я окреслив, ви виявите такі інструменти, як gitk, набагато ціннішими, оскільки це дозволяє чітко бачити групи змін.

Додаткова відповідь:

Git дуже гнучкий, і є кілька способів зробити те, що ви описуєте. Що слід пам’ятати, це завжди запускати нову гілку для кожної функції, над якою ви працюєте. Це означає, що головну гілку не торкаються, тому ви завжди можете повернутися до неї, щоб виправити помилки. Працюючи в git, майже завжди слід починати з:

git checkout -b new-feature-a

Тепер ви можете редагувати файл a.txt. Щоб одночасно працювати над іншою функцією, виконайте такі дії:

git checkout master
git checkout -b new-feature-z

Тепер ви можете редагувати файл z.txt. Щоб повернутися до a.txt:

git checkout new-feature-a

Але зачекайте, є зміни до new-feature-z, і git не дозволить вам перемикати гілки. На даний момент у вас є два варіанти вибору. Перший - найпростіший, фіксує всі зміни в поточній гілці:

git add .
git commit
git checkout new-feature-a

Це те, що я б рекомендував. Але якщо ви дійсно не готові зафіксувати код, ви можете тимчасово сховати його:

git stash

Тепер ви можете перейти на відділення new-feature-a. Щоб повернутися до коду, над яким ви працювали, просто витягніть схованку:

git checkout new-feature-z
git stash pop

Коли все зроблено, об'єднайте всі зміни в master:

git merge --no-ff new-feature-a
git merge --no-ff new-feature-z

Оскільки злиття відбувається настільки швидко і легко (легко, оскільки конфлікти є настільки рідкісними, і вирішення конфліктів, коли таке трапляється, не надто важке), ми використовуємо гілки в git для всього.

Ось ще один приклад поширеного використання гілок у git, якого ви не бачите в інших інструментах керування джерелами (крім, можливо, ртутного):

Потрібно продовжувати змінювати конфігураційні файли, щоб відображати середовище розробника? Потім використовуйте гілку:

git checkout -b dev-config

Тепер відредагуйте свої конфігураційні файли у вашому улюбленому редакторі, а потім внесіть зміни:

git add .
git commit

Тепер кожна нова гілка може починатися з гілки dev-config замість master:

git checkout dev-config
git checkout -b new-feature-branch

Після закінчення видаліть правки у dev-config з гілки new-feature за допомогою інтерактивної бази даних:

git rebase -i master

Видаліть коміти, які ви не хочете, а потім збережіть. Тепер у вас є чиста гілка без спеціальних змін конфігурації. Час об’єднати назад до master:

git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it's a good idea to rebase dev-config:
git checkout dev-config
git rebase master

Слід зазначити, що видалення редагувань git rebase -iнавіть працює, коли всі зміни відбуваються в одному файлі. Git запам'ятовує зміни, а не вміст файлу *.

* Примітка: насправді, технічно це не зовсім вірно, але як користувач саме це відчуває

Більше додаткової відповіді:

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

По-перше, слово про вплив дешевого розгалуження та змінної історії на ваш робочий процес. Коли я використовував CVS та SVN, я завжди був небажаний робити комісії. Це пов’язано з тим, що фіксація нестабільного коду неминуче зіпсує робочий код інших людей. Але з git я втратив цей страх. Це тому, що в git інші люди не отримають мої зміни, поки я не об’єднаю їх для засвоєння. Тож я зараз виявляю, що виконую код кожні 5 рядків, які я пишу. Вам не потрібно ідеального передбачення, щоб здійснити. Вам просто потрібно змінити своє мислення: commit-to-branch == add-to-changeset, merge-to-master == commit-changeset.

Отже, повернемось до прикладів. Ось як би я це зробив. Скажімо, у вас є гілка, new-feature-zі ви хочете перевірити її new-feature-a. Я б просто створив нову гілку для тестування:

# assume we are currently in branch new-feature-z
# branch off this branch for testing
git checkout -b feature-z-and-feature-a
# now temporarily merge new-feature-a
git merge --no-ff new-feature-a

Тепер ви можете протестувати. Якщо вам потрібно щось змінити, щоб функція-z працювала з функцією-a, зробіть це. Якщо так, ви можете об'єднати зміни до відповідної гілки. Використовуйте git rebase -iдля видалення нерелевантних змін із об’єднання.

Крім того, ви також можете використовувати git rebase, щоб тимчасово змінити базу new-feature-z на вказівку на new-feature-a:

# assume we are currently in branch new-feature-z
git rebase new-feature-a

Тепер історія гілок модифікована таким чином, що new-feature-z буде базуватися на new-feature-a замість master. Тепер ви можете протестувати. Будь-які зміни, допущені в цій гілці, належатимуть до гілки new-feature-z. Якщо вам потрібно змінити нову функцію-a, просто поверніться до неї та перебазуйте, щоб отримати нові зміни:

git checkout new-feature-a
# edit code, add, commit etc..
git checkout new-feature-z
git rebase new-feature-a
# now new-feature-z will contain new changes from new-feature-a

Закінчивши, просто перебазіруйте назад до master, щоб видалити зміни з new-feature-a:

# assume we are currently in branch new-feature-z
git rebase master

Не бійтеся відкривати нову гілку. Не бійтеся розпочати викидну гілку. Не бійтеся викидати гілки. І оскільки merge == submit і commit == add-to-changeset, не бійтеся часто фіксувати. Пам’ятайте, коміт - це головний інструмент скасування розробника.

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

У мене недостатньо досвіду p4, щоб створити справжню шпаргалку, але є принаймні деякі подібності, на які можна повернутися. P4 "набір змін" - це git "коміт".

Зміни у вашому локальному робочому просторі додаються до "індексу" за допомогою git add, а індекс згодом фіксується за допомогою git commit. Отже, індекс - це ваш список змін, що очікує на розгляд, для всіх намірів і цілей.

Ви переглядаєте зміни за допомогою git diffта git status, де git diffзазвичай відображаються зміни між робочою областю та індексом, але git diff --cachedвідображаються зміни між індексом та сховищем (= ваш список змін, що очікує на розгляд).

Для отримання більш детальної інформації я рекомендую http://progit.org/book/ . Оскільки ви знаєте контроль версій загалом, ви, напевно, можете його багато очистити та витягти інформацію, специфічну для git ...

Я страждаю, як і ви, через відсутність концепції "списку змін", яка не зовсім така сама, як git гілки.

Я б написав невеликий скрипт, який створить файл списку змін зі списком файлів у цьому списку змін.

Ще одна команда подати лише певний список змін, просто викликавши git commit -a @ change_list_contents.txt, а потім "git commit"

Сподіваюся, це допоможе, Еліас

У git є більш легка альтернатива, яка може стати частиною вашого робочого процесу; з використанням області встановлення git.

Я часто просто вношу зміни, а потім подаю у вигляді декількох комітів (наприклад, додаю оператори налагодження, рефактор, фактично виправляю помилку). Замість того, щоб налаштовувати свої списки змін perforce, потім внесіть зміни, а потім надішліть, ви можете просто внести свої зміни, а потім вибрати спосіб їх подання (за бажанням, використовуючи область підстановки git).

Ви можете зафіксувати певні файли з командного рядка за допомогою:

git commit a.txt
git commit z.txt

Або спочатку інсценування файлів:

git add a.txt
git commit
git add z.txt
git commit

git gui дозволить вам вибирати рядки або фрагменти з файлів, щоб створити коміт у проміжній області. Це дуже корисно, якщо у вас є зміни в одному файлі, які ви хочете бути в різних комітах. Перейшовши від git до perforce, і це одна річ, якої я дуже скучаю.

З цим робочим процесом слід пам’ятати невелике застереження. Якщо ви внесете зміни до файлів A та B, протестуйте файл, а потім зафіксуйте A, тоді ви не перевірили цей коміт (незалежно від B).

Це конкретно не відповідає на ваше запитання, але я не знаю, чи знаєте ви, що версію perforce для 2 користувачів та 5 робочих областей можна безкоштовно завантажити та використовувати з веб-сайту perforce .

Таким чином, ви можете використовувати perforce вдома для своїх особистих проектів, якщо хочете. Однією з прикрощів є 5 робочих областей, які можуть бути дещо обмежувальними, але це неймовірно, що продуктивність доступна для домашнього використання.

Досить широко використовуючи і Perforce, і git, я бачу лише один спосіб дістатися до списку змін Percece за допомогою git.

Перше, що слід зрозуміти, це те, що для правильної реалізації цієї функціональності в git таким чином, що це не повний клуб, наприклад, спроба підбити його на гілки, буде потрібно наступна зміна: git вимагатиме декількох областей прогону для однієї гілки .

Списки змін perforce дозволяють робочий процес, який просто не має еквівалента в git. Розглянемо такий робочий процес:

Check out a branch
Modify file A and add it to changelist 1
Modify file B and add it to changelist 2

Якщо ви спробуєте зробити це за допомогою гілок у git, ви отримаєте дві гілки, одна з яких має зміни до файлу A, інша - до файлу B, але немає місця, де ви можете побачити зміни до обох файлів Aта Bна в той же час.

Найближче наближення, яке я бачу, - це використання, git add . -pа потім використання підкоманд 'a'та та 'd'для вибору або відхилення цілих файлів. Однак це не зовсім однаково, і різниця тут походить від принципової диспропорції в загальному режимі роботи двох систем.

Git (і диверсія, не те, що це важливо для цієї дискусії) дозволяє змінити файл, не повідомляючи нікому про це заздалегідь. Ви просто змінюєте файл, а потім дозволяєте git все це сортувати, коли фіксуєте зміни. Perforce вимагає від вас активного перегляду файлу до того, як дозволено вносити зміни, і саме з цієї причини повинні існувати списки змін. По суті, Perforce вимагає від вас додати файл до індексу перед його зміною. Звідси необхідність у декількох списках змін у Perforce, а також причина, чому git не має еквівалента. Вони йому просто не потрібні.

З Git 2.27 (Q2 2020) " git p4" вивчив чотири нові хуки, а також " --no-verify" можливість обходу їх (і " p4-pre-submit" існуючого " " гачка).

Див. Коміт 1ec4a0a , коміт 38ecf75 , коміт cd1e0dc (14 лютого 2020 р.) Та коміт 4935c45 , коміт aa8b766 , коміт 9f59ca4 , коміт 6b602a2 (11 лютого 2020 р.) Бен Кіні ( seraphire) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 5f2ec21 , 22 квітня 2020 р.)}

git-p4: додати p4 подати гачки

^{Підписав: Бен Кіні}

Команда git " commit" підтримує ряд хуків, які підтримують зміну поведінки команди коміту.

git-p4.pyПрограма має тільки один існуючий гачок, « p4-pre-submit».

Ця команда відбувається на початку процесу.

У процесі обробки немає гачків для програмної модифікації тексту списку змін P4.

Додає 3 нові гачки до git-p4.pyопції подання.

Нові гачки:

• p4-prepare-changelist- Виконайте цей гачок після створення файлу списку змін.
  Гак буде виконаний, навіть якщо --prepare-p4-onlyопція встановлена.
  Цей хук ігнорує --no-verifyопцію відповідно до існуючої поведінки git commit.

• p4-changelist- Виконайте цей хук після того, як користувач відредагував список змін.
  Не виконуйте цей хук, якщо користувач вибрав цю --prepare-p4-onlyопцію.
  Цей гачок буде на честь --no-verify, дотримуючись конвенцій Росії git commit.

• p4-post-changelist- Виконайте цей хук після успішного завершення процесу подання P4.
  Цей гачок не приймає жодних параметрів і виконується незалежно від --no-verifyопції.

Його повернене значення не перевірятиметься.

Заклики до нових гачками: p4-prepare-changelist, p4-changelistі p4-post-changelistвсі повинні називатися всередині примірки , нарешті , блок.

До Git 2.28 (Q3 2020) --prepare-p4-onlyопція " " повинна зупинитися після відтворення одного набору змін, але продовжувала працювати (помилково?)

Див. Коміт 2dfdd70 (12 травня 2020 р.) Бен Кін ( seraphire) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 7a8fec9 , 02 червня 2020 р.)}

git-p4.py: виправити --prepare-p4-onlyпомилку з кількома комітами

^{Підписав: Бен Кіні}

При використанні git p4 submitз --prepare-p4-onlyопцією програма повинна підготувати єдиний список змін p4 та повідомити користувача, що очікує більше комітів, а потім припинити обробку.

Помилка була введена функцією p4-changelistпідключення, яка змушує програму продовжувати намагатися обробляти всі очікувані списки змін одночасно.

Функція applyCommitповертається, Trueколи застосування коміту було успішним, і програма повинна продовжуватись.
Однак, коли встановлений додатковий прапор --prepare-p4-only, програма повинна зупинитися після першого застосування.

Змініть логіку методу запуску для P4Submit, щоб перевірити прапор --prepare-p4-onlyпісля успішного завершення applyCommitметоду.

Якщо більше ніж 1 коміт очікує подання на P4, метод належним чином підготує список змін P4, однак він все одно вийде із програми з кодом виходу 1.

Поточна документація не визначає , що код виходу повинен бути в цьому стані.