1

Еще до того, как я услышал о чудесах управления версиями, я хранил проекты в папках, таких как «проект х 1.0», «проект х 1.1», «проект х 1.2» и т.д. В этом подходе есть тонны избыточности, поэтому я бы нравится использовать git для консолидации и контроля версий системы на будущее.

Какой лучший способ сделать это? Я предполагаю, что мне следует начать с запуска git init в «проекте x 1.0», но как я могу консолидировать другие папки в проекте в качестве новых коммитов? (Я все еще очень плохо знаком с Git)

3 ответа3

4

Я бы начал с создания нового пустого каталога, создания в нем репозитория с помощью git init и выполнения первого коммита с использованием только файла .gitignore или чего-то в этом роде.

Затем скопируйте все файлы из вашей первой ревизии в этот новый каталог, git add и git commit . Это даст вам ваш первый настоящий коммит.

Затем скопируйте / перезапишите все файлы с содержимым вашей второй ревизии. git add , git commit .

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

3

Есть хорошая книга для Git под названием Pro Git. Также есть раздел о том, как перейти с пользовательской структуры. (См. Пользовательский импортер). Это немного сложнее, но если у вас много истории, то это будет лучшим способом.

Другой способ это сделать:

# initialize a new repository
git init .
touch .gitignore
git add .
git commit -m "initial commit"

# copy all the files to working directory
cp -R backup_v01/* .
# stage all the files
git add .
# make the first commit
git commit -m "v0.1 from backup"

# remove all files
git rm -r *
# copy all the files to working directory
cp -R backup_v02/* .
git add .
git commit -m "v0.2 from backup"

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

Конечно, все это можно превратить в скрипт (repo.sh):

#!/bin/bash
REPODIR=$1

# initialize a new repository
git init $REPODIR

cd $REPODIR
touch .gitignore
git add .
git commit -m "initial commit"

while read DIR
do
  # remove all files
  git rm -r *
  # copy all the files to working directory
  cd ..
  cp -R $DIR/* $REPODIR/.
  # go back to repo dir
  cd $REPODIR
  # stage all the files
  git add .
  # make the first commit
  git commit -m "$DIR from backup"
done

Переключение папки необходимо, чтобы она работала с относительными путями.

Вы используете его, отправляя все пути к папкам в сценарий и указывая каталог хранилища (он не должен существовать):

# let's say all the backups are in this folder
# and there are no other folders

# test whether everything is in correct order
ls -d */ | sort

# verify that there is no repository directory
rm -rf REPO_DIR

# pipe the folder listing to the script
ls -d */ | sort | repo.sh REPO_DIR
2

Другим способом было бы, после init и фиксации в вашей первой версии проекта, переместить каталог репозитория .git из вашей копии 1.0 в вашу копию 1.1, добавить эти изменения (используйте git add --all чтобы заметить удаления) и зафиксировать, затем переместите его на 1.2 и так далее.

Это работает, потому что Git не хранит никакой информации о состоянии хранилища за пределами каталога .git , поэтому его не волнует, что вы перемещаете .git а не заменяете файлы. Однако, если у вас есть, например, файлы, которые вы хотите игнорировать с помощью .gitignore , для этого потребуется добавить файл игнорирования в каждую версию проекта отдельно.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .