Некоторые системы управления версиями, например Perforce, сохраняют CL как простое целое число, поэтому, глядя на два разных CL на одной ветви, легко понять, какой CL был сначала скомпонован. Но в случае Git CL/short CL - длинная шестнадцатеричная строка, которая даже не сравнима с человеческими глазами. Есть ли способ избавиться от этой проблемы?Идентификаторы с изменяемой информацией/сопоставимые идентификаторы git
Боюсь, что нет. Распределенный характер системы исключает хороший монотонно увеличивающийся «номер пересмотра». Если вы и кто-то другой на другой стороне земного шара решили совершить (не нажимать) патч точно в то же время, кто есть версия n и кто n+1? Такая синхронизация возможна только тогда, когда имеется один центральный сервер, который может назначать номера ревизий. Это плата за распространение.
Однако, несмотря на отсутствие технических решений, существуют социальные решения. Хорошие имена ветвей, правильная маркировка помогают понять, что происходит с проектом. git branch --merged и --no-merged расскажут о том, какие ветки объединены, а какие нет.
(Это правильный ответ и поддерживается.) Также стоит отметить, что при использовании тегов вы также можете использовать 'git describe'. Это пытается вычислить несколько дружественное человеку число, создавая выход формы «
Вывод описания, ветвей, тегов и нескольких других примеров - это примеры того, что называется [treeish] (http://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git#18605496) s в git. –
На самом деле они «готовы», но, конечно, все, что идентифицирует фиксацию, везде, где требуется дерево, разрешает дерево. Несколько команд, таких как 'git show', получат доступ к фиксации; в этом случае вы можете использовать суффикс '^ {tree}' из gitrevisions, чтобы принудительно преобразовать идентификатор фиксации в соответствующий идентификатор дерева. – torek
Нет, хэш SHA-1 для git - строка из 40 символов. Он рассчитан на основе содержимого файлов. И git olny хранит SHA-1 в базе данных. Поэтому он не читается для глаз человека.
Если вы хотите проверить историю git, то git log --oneline --decorate --graph --all является ясным для просмотра.
Именно поэтому каждая фиксация в Git имеет связанный с ней _message_ и, возможно, и тег. –
не знаю, почему кто-то проголосовал. –
Это был не я, потому что это того стоит. –