Я не очень часто использовал перформанс, поэтому это может быть не совсем перевод 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
Но если вы хотите узнать разницу между тем, что вы печатаете сейчас, и последним коммитом, тогда вы действительно запрашиваете разницу междурабочий каталог + индекс и ГОЛОВКА:
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 очень гибок, и есть несколько способов сделать то, что вы описываете.Помните, что всегда нужно начинать новую ветку для каждой функции, над которой вы работаете.Это означает, что ветка master не затрагивается, поэтому вы всегда можете вернуться к ней, чтобы исправить ошибки.Работая в 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
Когда все будет сделано, объедините все изменения с мастером:
git merge --no-ff new-feature-a
git merge --no-ff new-feature-z
Поскольку слияния происходят так быстро и легко (просто потому, что конфликты настолько редки, а разрешение конфликтов, когда оно происходит, не слишком сложно), мы используем ветки в git для всего.
Вот еще один пример общего использования веток в git, которого вы не видите в других инструментах контроля версий (кроме, возможно, mercurial):
Вам нужно постоянно изменять файлы конфигурации, чтобы они отражали вашу среду разработки? Тогда используйте ветку:
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-branch с помощью интерактивной перебазировки:
git rebase -i 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 другие люди не получат мои изменения, пока я не объединю их с мастером. Так что теперь я обнаруживаю, что я записываю код каждые 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
Теперь вы можете проверить. Если вам нужно что-то изменить, чтобы Feature-Z работал с Feature-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. Если вам нужно изменить new-feature-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
Когда вы закончите, просто вернитесь к мастеру, чтобы удалить изменения из new-feature-a:
# assume we are currently in branch new-feature-z
git rebase master
Не бойтесь начать новую ветку. Не бойтесь начать одноразовую ветку. Не бойтесь выбрасывать ветви. А поскольку слияния == отправить и зафиксировать == добавить-для-изменения, не бойтесь часто совершать. Помните, что commit - это лучший инструмент для отмены действий разработчика.
Да, и еще одна вещь, в git удаленные ветки все еще существуют в вашем хранилище. Так что, если вы случайно удалили что-то, что позже вы поймете, полезно, в конце концов, вы всегда можете получить его обратно, просматривая историю. Так что не бойтесь выбрасывать ветви.