Ответ 1
Я не использовал 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 filenameGit gui занимает больше времени, чтобы проанализировать файл (он был написан в tcl вместо C), но он имеет множество опрятных функций, включая возможность "путешествовать во времени" обратно в прошлое, нажав на идентификатор фиксации. Я только хочу, чтобы они реализовали функцию "путешествия во времени" в будущее, чтобы я мог узнать, как окончательно решить данную ошибку; -)
-
Для данного файла см. список описаний списков изменений, которые повлияли на файл → также легко:
git log filenameНо git log - гораздо более мощный инструмент, чем просто этот. На самом деле большинство моих личных скриптов выгружают из git log для чтения репозитория. Прочтите страницу руководства.
-
Отправить ожидающий список изменений → Также легко:
git commit
См. мой ответ на предыдущий вопрос, чтобы увидеть мой типичный рабочий процесс git: Обучение 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 с помощью интерактивной rebase:
git rebase -i master
Удалите коммиты, которые вы не хотите, затем сохраните. Теперь у вас есть чистая ветка без пользовательских настроек конфигурации. Время для слияния с мастером:
git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it a good idea to rebase dev-config:
git checkout dev-config
git rebase master
Следует отметить, что удаление изменений с помощью git rebase -i даже работает, когда все изменения происходят в одном файле. git запоминает изменения, а не содержимое файла *.
* Примечание: на самом деле, технически не совсем верно, но как пользователь, что он чувствует себя
Дополнительный ответ:
Итак, из ваших комментариев, похоже, вы хотите, чтобы одновременно существовали две ветки, чтобы вы могли проверить, как работает комбинированный код. Ну, это хороший способ показать силу и гибкость ветвей.
Во-первых, слово о влиянии дешевой ветвящейся и модифицируемой истории на ваш рабочий процесс. Когда я использовал CVS и SVN, я всегда был немного неохотным. Это из-за того, что выполнение неустойчивого кода неизбежно f ** k над другим рабочим кодом. Но с 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, чтобы указать на новую функцию-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. Если вам нужно изменить новую функцию - просто вернитесь к ней и переформатируйте, чтобы получить новые изменения:
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
Когда вы закончите, просто переустановите мастер для удаления изменений из new-feature-a:
# assume we are currently in branch new-feature-z
git rebase master
Не бойтесь начать новую ветку. Не бойтесь начать отброшенную ветку. Не бойтесь выбросить ветки. И поскольку merge == submit и commit == add-to-changeset не боятся совершать часто. Помните, что commit - это инструмент отмены от разработчика.
О, и еще одна вещь, в git удаленные ветки все еще существуют в вашем репозитории. Поэтому, если вы случайно удалили то, что позже понимаете, полезно после всего, что вы всегда можете вернуть его, просмотрев историю. Так что не бойтесь выбросить ветки.