Làm thế nào để sửa chữa kho lưu trữ git bị hỏng?


104

Tôi đã thử nhân bản kho lưu trữ của mình mà tôi giữ trên Ubuntu của mình một thư mục sang một máy mới và tôi nhận được điều này:

christopher@christopher-laptop:~/source/personal$ git clone ~/Ubuntu\ One\ Side\ Work/projects.git/
Cloning into 'projects'...
done.
fatal: unable to read tree 29a422c19251aeaeb907175e9b3219a9bed6c616
christopher@christopher-laptop:~/source/personal$ 

Vì vậy, tôi đã thử xem xét nhiều câu hỏi khác như thế này đã được hỏi ở đây và hầu hết trong số họ nói rằng hãy chạy git fsck --fullvà sau đó tôi nhận được điều này khi tôi thử điều đó.

christopher@christopher-laptop:~/Ubuntu One Side Work/projects.git$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (447/447), done.
broken link from  commit 235ae1f48701d577d71ebd430344a159e5ba4881
              to  commit 984c11abfc9c2839b386f29c574d9e03383fa589
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    blob 25a742dff0a403b2b3884f2ffddf63eb45721fac
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    blob dd4e97e22e159a585b20e21028f964827d5afa4e
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    tree 29a422c19251aeaeb907175e9b3219a9bed6c616
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    tree 8084e8e04d510cc28321f30a9646477cc50c235c
broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628
              to    blob a0daa0c1567b55d8de2b4d7a3bc010f58c047eab
broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628
              to    blob e9052d35bfb6d30065b206fc43f4200a04d5281b
broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628
              to    blob 1a3a5e4dd2502ac121c22f743c4250e254a94eeb
broken link from    tree 4aa336dc1a5838e8918e03b85580069d83f4ad09
              to    tree 8cc55ec952dc192a233e062201d1e7e873ac3db0
broken link from    tree e5674a91a53e15575a1f3bf5786bc5cc719fb483
              to    blob 4a994e1e7bb7ce28dcec98bad48b9a891d7dec51
broken link from    tree e5674a91a53e15575a1f3bf5786bc5cc719fb483
              to    blob ac033bf9dc846101320c96a5ce8aceb8c96ec098
broken link from    tree 252ab84542264e1589576b6ee51e7a31e580a0e2
              to    tree 2069041cd5950e529e2991d37b7290ec021d90d4
broken link from    tree 2d4964aa4d4f5d8c7228518ce72ef6a63f820c6d
              to    blob d83690e1b9a6bdd8a08754b38231799acefcb2ab
broken link from    tree c7192e82fc581bd6448bda1a25e8729bdac5f4ff
              to    blob 30d54d47ae82add1917ca173d42e58b396df580b
broken link from    tree 7c66306901fc71389623286936cef172d4ffe408
              to    blob bc7e05d705401273b1df4e939de0f540597c0931
broken link from    tree 0940f5fd227d4c84d6e6749d872db50a4522ae3a
              to    tree 923767594ac22023e824948d65622fe5b407d1a1
broken link from    tree 8eadcd2a971e8357d24f0d80f993d2963452209f
              to    blob 2598bde3dc8cb80ee49510b8159344004b88645f
broken link from    tree ffa302dd0d969172ef23caeefe856ab2f57a4e4d
              to    blob d6925fa431be1ac585bf9a481e98f75107a6e6fb
broken link from    tree 7045b8870a49ce30a2027537a96d73d162bda773
              to    blob 25688652dea26f61f576ca1b52b9d1a18fbfd01d
broken link from    tree 37e4705d34bd440ce681ae32ae9a180a13256d72
              to    tree 246f564d4cee53339b8a4244f3173b61caa518eb
missing blob d6925fa431be1ac585bf9a481e98f75107a6e6fb
missing blob ac033bf9dc846101320c96a5ce8aceb8c96ec098
missing tree 29a422c19251aeaeb907175e9b3219a9bed6c616
missing tree 8084e8e04d510cc28321f30a9646477cc50c235c
missing blob 30d54d47ae82add1917ca173d42e58b396df580b
missing tree 8cc55ec952dc192a233e062201d1e7e873ac3db0
missing blob e9052d35bfb6d30065b206fc43f4200a04d5281b
dangling tree 4b26e95db542c72ac4a22ec25abe38fb2de79752
missing blob d83690e1b9a6bdd8a08754b38231799acefcb2ab
missing blob 25a742dff0a403b2b3884f2ffddf63eb45721fac
missing tree 923767594ac22023e824948d65622fe5b407d1a1
missing blob 25688652dea26f61f576ca1b52b9d1a18fbfd01d
missing blob 2598bde3dc8cb80ee49510b8159344004b88645f
dangling tree 3a683869f1bb0c1634de75700c316b3b36570dbd
dangling blob 4098d30843380d798a811f1aa9a02994f0dbbb27
missing tree 2069041cd5950e529e2991d37b7290ec021d90d4
missing blob 4a994e1e7bb7ce28dcec98bad48b9a891d7dec51
missing blob 1a3a5e4dd2502ac121c22f743c4250e254a94eeb
missing blob a0daa0c1567b55d8de2b4d7a3bc010f58c047eab
dangling tree 6c7b5162aa7a303fa3fe8dc393c5da564e309521
missing commit 984c11abfc9c2839b386f29c574d9e03383fa589
missing blob bc7e05d705401273b1df4e939de0f540597c0931
missing blob dd4e97e22e159a585b20e21028f964827d5afa4e
missing tree 246f564d4cee53339b8a4244f3173b61caa518eb
dangling commit a01f5c1e5315dc837203d6dee00d3493be9c5db9

Trông thật tệ. Khi tôi làm một git log | headtôi nhận được điều này

christopher@christopher-laptop:~/Ubuntu One Side Work/projects.git$ git log | head
error: Could not read 984c11abfc9c2839b386f29c574d9e03383fa589
fatal: Failed to traverse parents of commit 235ae1f48701d577d71ebd430344a159e5ba4881
commit 2fb0d2d0643b445440f01b164f11ee9ee71fca48
Author: christopher <christopher@christopher.christopher>
Date:   Wed Aug 7 15:51:42 2013 -0400

    finishing chapter 7

Các câu hỏi khác ở đây đã nói để xem xét ./git/refs/heads/master. Đó là một repo trần và refs/heads/tồn tại nhưng refs/heads/masterkhông. HEAD trong repo trần nói ref: refs/heads/mastermặc dù

packed-refs không nói điều này mặc dù

# pack-refs with: peeled 
2fb0d2d0643b445440f01b164f11ee9ee71fca48 refs/heads/master

Vẫn còn các câu hỏi khác đã đề xuất chạy git reflogvà không có đầu ra nào hiển thị khi tôi chạy điều đó.

Vì vậy, tôi thực sự không biết phải làm gì ở đây. Chiến lược nào nên được thực hiện? Có thể đặt lại đầu về cam kết cuối cùng này vào ngày 7 tháng 8 không

BIÊN TẬP:

Thực hiện nhật ký git và đi đến cuối màn hình xuất hiện điều này:

commit 996e03b949aea176238e3c7a8452700bbb987ac9
Author: christopher <christopher@christopher>
Date:   Wed Jul 3 23:00:44 2013 -0400

    many many changes
error: Could not read 984c11abfc9c2839b386f29c574d9e03383fa589
fatal: Failed to traverse parents of commit 235ae1f48701d577d71ebd430344a159e5ba4881

Điều đó dường như đang ngăn chặn git tỉa hoạt động


3
Điều này không giúp ích nhiều nhưng: không lưu trữ các kho lưu trữ Git trong Dropbox hoặc bất kỳ dịch vụ đồng bộ nào khác. Git không được xây dựng để xử lý một chương trình khác khóa và ghi lại các tệp một cách ngẫu nhiên trong khi nó đang làm việc khác.
millimoose


2
Gần như tất cả các câu trả lời đều giả định rằng người ta có thể đơn giản sao chép lại từ một nguồn gốc từ xa không thể sửa chữa được. Đây là vấn đề ... Nếu bạn nguồn gốc, và bạn bị hỏng? Đúng. Vì vậy, đây: git-repairlà một chương trình sẽ chạy git fsckvà cố gắng khắc phục mọi sự cố mà nó gặp phải. git-repair.branchable.com Nó có vẻ khá khả năng và mặc dù bạn có thể phải sao chép (nếu có thể!) các đối tượng từ một bản sao lưu (bạn có một bản sao lưu, phải không?), nó sẽ giúp bạn tiết kiệm rất nhiều thời gian bằng cách tận dụng bất cứ thứ gì có thể và để lại cho bạn công việc thực sự, không phải nhiều tác vụ có thể tự động hóa. Không có liên kết, v.v.
underscore_d

Câu trả lời:


110

Để thay thế cho tùy chọn cuối cùng của CodeGnome, nếu chỉ repo cục bộ bị hỏng và bạn biết url của điều khiển từ xa, bạn có thể sử dụng điều này để đặt lại .gitcho phù hợp với điều khiển từ xa (thay thế ${url}bằng url từ xa):

mv -v .git .git_old &&            # remove old git
git init &&                       # initialise new repo
git remote add origin "${url}" && # link to old repo
git fetch &&                      # get old history
git reset origin/master --mixed   # force update to old history

Điều này sẽ giữ nguyên cây làm việc của bạn và chỉ ảnh hưởng đến việc ghi sổ của git.
Gần đây tôi cũng đã tạo một tập lệnh bash cho mục đích này (Phụ lục A), bao gồm một chút an toàn xung quanh hoạt động này.

Ghi chú:

Nếu repo của bạn có các mô-đun con, quá trình này sẽ làm chúng rối tung bằng cách nào đó và giải pháp duy nhất mà tôi tìm thấy cho đến nay là xóa chúng và sau đó sử dụng git submodule update --init(hoặc sao chép lại repo, nhưng điều đó có vẻ quá quyết liệt).

Phụ lục A - Tập lệnh đầy đủ

#!/bin/bash

# Author: Zoey Llewellyn "Zobean" Hewll
#
# Usage: fix-git [REMOTE-URL]
#   Must be run from the root directory of the repository.
#   If a remote is not supplied, it will be read from .git/config
# 
# For when you have a corrupted local repo, but a trusted remote.
# This script replaces all your history with that of the remote.
# If there is a .git, it is backed up as .git_old, removing the last backup.
# This does not affect your working tree.
#
# This does not currently work with submodules!
# This will abort if a suspected submodule is found.
# You will have to delete them first
# and re-clone them after (with `git submodule update --init`)
#
# Error codes:
# 1: If a url is not supplied, and one cannot be read from .git/config
# 4: If the url cannot be reached
# 5: If a git submodule is detected


if [[ "$(find -name .git -not -path ./.git | wc -l)" -gt 0 ]] ;
then
    echo "It looks like this repo uses submodules" >&2
    echo "You will need to remove them before this script can safely execute" >&2
    echo "Then use \`git submodule update --init\` to re-clone them" >&2
    exit 5
fi

if [[ $# -ge 1 ]] ;
then
    url="$1"
else
    if ! url="$(git config --local --get remote.origin.url)" ;
    then
        echo "Unable to find remote 'origin': missing in '.git/config'" >&2
        exit 1
    fi
fi
url_base="$(echo "${url}" | sed -E 's;^([^/]*://)?([^/]*)(/.*)?$;\2;')"
echo "Attempting to access ${url_base} before continuing"
if ! wget -p "${url_base}" -O /dev/null -q --dns-timeout=5 --connect-timeout=5 ;
then
    echo "Unable to reach ${url_base}: Aborting before any damage is done" >&2
    exit 4
fi

echo
echo "This operation will replace the local repo with the remote at:"
echo "${url}"
echo
echo "This will completely rewrite history,"
echo "but will leave your working tree intact"
echo -n "Are you sure? (y/N): "

read confirm
if ! [ -t 0 ] ; # i'm open in a pipe
then
    # print the piped input
    echo "${confirm}"
fi
if echo "${confirm}"|grep -Eq "[Yy]+[EeSs]*" ; # it looks like a yes
then
    if [[ -e .git ]] ;
    then
        # remove old backup
        rm -vrf .git_old | tail -n 1 &&
        # backup .git iff it exists
        mv -v .git .git_old
    fi &&
    git init &&
    git remote add origin "${url}" &&
    git config --local --get remote.origin.url | sed 's/^/Added remote origin at /' &&
    git fetch &&
    git reset origin/master --mixed
else
    echo "Aborting without doing anything"
fi

3
Thật ngoạn mục, tôi đã sao lưu dự án của mình và thử giải pháp của bạn. Git đã bị hỏng khá nặng bằng cách nào đó. Tôi đã thử giải pháp của bạn và nó hoạt động hoàn hảo, cảm ơn bạn rất nhiều.
kequc

2
không sử dụng tập lệnh khi tôi đang sử dụng Windows, nhưng các lệnh đó chỉ lưu thư mục .git của tôi đang hiển thị kho lưu trữ mới cho mỗi lần lưu được thực hiện trên bất kỳ tệp được theo dõi nào (vì vậy tôi đã kết thúc với 50 kho lưu trữ chính trước khi thử sửa lỗi này )
moped

1
Tôi đã có thể khôi phục .gitthư mục của mình sau khi thực hiện việc này. Tôi thấy git reset origin/master --hardnó hữu ích hơn --mixed.
Felipe Alvarez,

1
Tuyệt quá. Trong trường hợp có các mô-đun con không chứa các thay đổi, hãy xóa chúng trước rồi thực hiện init mô-đun con để lấy lại.
herm 13/02/19

1
@ w33haa Rất tiếc, giải pháp này chỉ áp dụng cho trường hợp bạn có một kho lưu trữ từ xa hợp lệ và có thể truy cập được. Một số câu trả lời khác giải quyết trường hợp điều khiển từ xa không truy cập được hoặc bị hỏng.
Zoey Hewll

53

TL; DR

Git không thực sự lưu trữ lịch sử theo cách bạn nghĩ. Nó tính toán lịch sử tại thời điểm chạy dựa trên chuỗi tổ tiên. Nếu tổ tiên của bạn bị thiếu các đốm màu, cây cối hoặc các dấu vết thì bạn có thể không khôi phục được hoàn toàn lịch sử của mình.

Khôi phục các đối tượng bị thiếu từ bản sao lưu

Điều đầu tiên bạn có thể thử là khôi phục các mục bị thiếu từ bản sao lưu. Ví dụ: hãy xem liệu bạn có bản sao lưu của cam kết được lưu trữ dưới dạng không .git/objects/98/4c11abfc9c2839b386f29c574d9e03383fa589. Nếu vậy bạn có thể khôi phục lại nó.

Bạn cũng có thể muốn xem xét các đối tượng git-verify-packgit-unpack- trong trường hợp cam kết đã được đóng gói và bạn muốn trả lại nó về một đối tượng rời cho mục đích giải phẫu kho lưu trữ.

Phẫu thuật cắt bỏ

Nếu bạn không thể thay thế các mục bị thiếu từ bản sao lưu, bạn có thể loại bỏ lịch sử bị thiếu. Ví dụ: bạn có thể kiểm tra lịch sử hoặc reflog của mình để tìm tổ tiên của commit 984c11abfc9c2839b386f29c574d9e03383fa589. Nếu bạn tìm thấy một cái còn nguyên vẹn, thì:

  1. Sao chép thư mục làm việc Git của bạn vào một thư mục tạm thời ở đâu đó.
  2. Thực hiện khôi phục cài đặt gốc cho cam kết không bị gián đoạn.
  3. Sao chép các tệp hiện tại của bạn trở lại cây công việc Git, nhưng hãy đảm bảo rằng bạn không sao chép lại thư mục .git!
  4. Cam kết cây công việc hiện tại và cố gắng hết sức để coi nó như một bản cam kết bị bóp nghẹt của tất cả lịch sử còn thiếu.

Nếu nó hoạt động, bạn tất nhiên sẽ mất lịch sử can thiệp. Tại thời điểm này, nếu bạn có nhật ký lịch sử làm việc, thì bạn nên lược bớt lịch sử của mình và ghi lại tất cả các cam kết và đối tượng không thể truy cập.

Khôi phục hoàn toàn và khởi tạo lại

Nếu kho lưu trữ của bạn vẫn bị hỏng, thì hy vọng bạn có một bản sao lưu hoặc bản sao không bị gián đoạn mà bạn có thể khôi phục từ đó. Nếu không, nhưng thư mục làm việc hiện tại của bạn chứa các tệp hợp lệ, thì bạn luôn có thể khởi tạo lại Git. Ví dụ:

rm -rf .git
git init
git add .
git commit -m 'Re-initialize repository without old history.'

Nó rất quyết liệt, nhưng nó có thể là lựa chọn duy nhất của bạn nếu lịch sử kho lưu trữ của bạn thực sự không thể khôi phục được. YMMV.


3
Tôi vừa gặp phải vấn đề này và muốn chỉ ra điều này vì nó không có trong câu trả lời của bạn, nhưng vấn đề của tôi chỉ là vấn đề về quyền đơn giản. error: Could not read abcdeKho lưu trữ của tôi do GitLab quản lý và nó đang tạo các tệp mà người dùng của tôi không thể đọc được. Một lúc sudo chownsau và tôi đã tốt để đi.
Aust

6

Nếu bạn đã định cấu hình một điều khiển từ xa và bạn có / không quan tâm đến việc mất một số mã chưa được đẩy, bạn có thể làm:

git fetch && git reset --hard

2
Trong một số trường hợp, git sẽ không cho phép bạn tìm nạp nếu một số đối tượng nhất định bị hỏng, vì vậy trước tiên bạn cần khởi tạo lại repo của mình.
Zoey Hewll

Điều này không hiệu quả với tôi khi tôi có fatal: pack has 13 unresolved deltas.
Artem Russakovskii

5

Đây là một tập lệnh (bash) để tự động hóa giải pháp đầu tiên của @CodeGnome để khôi phục từ bản sao lưu (chạy từ cấp cao nhất của repo bị hỏng). Bản sao lưu không cần phải đầy đủ, nó chỉ cần có các đối tượng bị thiếu.

git fsck 2>&1 | grep -e missing -e invalid | awk '{print $NF}' | sort -u |
    while read entry; do
        mkdir -p .git/objects/${entry:0:2}
        cp ${BACKUP}/objects/${entry:0:2}/${entry:2} .git/objects/${entry:0:2}/${entry:2}
    done

4

Trước khi thử bất kỳ bản sửa lỗi nào được mô tả trên trang này, tôi khuyên bạn nên tạo một bản sao repo của bạn và chỉ làm việc trên bản sao này. Sau đó, cuối cùng nếu bạn có thể sửa chữa nó, hãy so sánh nó với bản gốc để đảm bảo bạn không bị mất bất kỳ tệp nào trong quá trình sửa chữa.

Một giải pháp thay thế khác phù hợp với tôi là đặt lại đầu git và chỉ mục về trạng thái trước đó bằng cách sử dụng:

git reset --keep

Bạn cũng có thể làm tương tự theo cách thủ công bằng cách mở Git GUI và chọn từng "Thay đổi theo giai đoạn" và nhấp vào "Bỏ gắn dấu sao cho thay đổi". Khi mọi thứ được gỡ bỏ, bây giờ bạn sẽ có thể nén cơ sở dữ liệu của mình, kiểm tra cơ sở dữ liệu và cam kết.

Tôi cũng đã thử các lệnh sau nhưng chúng không hoạt động với tôi, nhưng chúng có thể cho bạn tùy thuộc vào vấn đề chính xác mà bạn gặp phải:

git reset --mixed
git fsck --full
git gc --auto
git prune --expire now
git reflog --all

Cuối cùng, để tránh sự cố đồng bộ hóa này làm hỏng chỉ mục git của bạn (có thể xảy ra với DropBox, SpiderOak hoặc bất kỳ đĩa đám mây nào khác), bạn có thể làm như sau:

  1. Chuyển đổi .gitthư mục của bạn thành một tệp git "gói" duy nhất bằng cách sử dụng : git bundle create my_repo.git --all, sau đó nó sẽ hoạt động giống như trước đây, nhưng vì mọi thứ nằm trong một tệp duy nhất nên bạn sẽ không có nguy cơ đồng bộ hóa làm hỏng git repo của bạn nữa.
  2. Tắt đồng bộ hóa tức thời : SpiderOak cho phép bạn đặt lịch kiểm tra các thay đổi thành "tự động" (có nghĩa là càng sớm càng tốt, theo dõi các thay đổi của tệp nhờ thông báo của hệ điều hành). Điều này không tốt vì nó sẽ bắt đầu tải lên các thay đổi ngay sau khi bạn thực hiện thay đổi và sau đó tải xuống thay đổi, vì vậy nó có thể xóa các thay đổi mới nhất mà bạn vừa thực hiện. Giải pháp để khắc phục sự cố này là đặt độ trễ theo dõi thay đổi thành 5 phút hoặc hơn. Điều này cũng khắc phục sự cố với các ứng dụng ghi chú lưu tức thì (chẳng hạn như Notepad ++).

3

Nếu bạn đang tuyệt vọng, bạn có thể thử cách này:

git clone ssh://me@my.git.server/path/to/project destination --depth=1

Nó sẽ lấy dữ liệu của bạn, nhưng bạn sẽ mất lịch sử. Tôi đã thử và sai trên repo của mình và --depth=10làm việc, nhưng --depth=50đã thất bại.


3

Tôi đã thử di chuyển các tệp đối tượng có 0 byte và tìm nạp lại chúng từ điều khiển từ xa, và nó hoạt động:

find . -type f -size 0 -exec mv {} /tmp \;
git fetch

Nó lấy các đối tượng bị thiếu từ điều khiển từ xa và cho phép tôi tiếp tục làm việc mà không cần khởi động lại toàn bộ repo.


2

Tôi cũng gặp phải vấn đề tương tự, vì vậy tôi đã thay thế thư mục ".git" bằng một phiên bản đã sao lưu và nó vẫn không hoạt động do tệp .gitconfig bị hỏng. BSOD trên máy tính xách tay của tôi đã làm hỏng nó. Tôi đã thay thế nó bằng mã sau và sourcetree đã khôi phục tất cả các kho của tôi.

[user]
name = *your username*
email = *your email address*
[core]
autocrlf = true
excludesfile = C:\\Users\\*user name*\\Documents\\gitignore_global.txt

Tôi không biết liệu điều này có giúp được ai không, nhưng đây chỉ là một giải pháp khác phù hợp với tôi.


2

Xóa chỉ mục và đặt lại

rm -f .git/index
git reset

2

Gần đây, tôi đã gặp sự cố tương tự khi sử dụng git phiên bản 2.7.1 trong Ubuntu 18.04.3. Đây là cách tôi đã làm:

sudo apt install git-repair
git-repair  # fix a broken git repository
or
git-repair --force  # force repair, even if data is lost
git fsck  # to verify it was fixed

Hầu hết thời gian quá trình khôi phục thành công


git-repair thực sự là một công cụ rất hữu ích. Nó đã giúp tôi khôi phục một kho lưu trữ. Vấn đề với hầu hết các phương pháp khác là bạn mất số tiền lưu trữ của mình, đó không phải là một lựa chọn đối với tôi.
Jan Rychter

1

Trong trường hợp của tôi, tôi đang tạo kho lưu trữ từ mã nguồn đã có trong máy tính của mình và lỗi đó đã xuất hiện. Tôi đã xóa thư mục .git và làm lại mọi thứ và nó hoạt động :)


1

Tôi muốn thêm điều này làm bình luận dưới câu trả lời tuyệt vời của Zoey Hewil ở trên, nhưng tôi hiện không có đủ đại diện để làm như vậy, vì vậy tôi phải thêm nó vào đây và ghi nhận công sức của cô ấy: P

Nếu bạn đang sử dụng Poshgit và cảm thấy đặc biệt lười biếng, bạn có thể sử dụng cách sau để tự động trích xuất URL từ cấu hình git của bạn và thực hiện công việc đơn giản thậm chí còn dễ dàng hơn. Cảnh báo tiêu chuẩn áp dụng khi kiểm tra điều này trên một bản sao / sao lưu repo cục bộ của bạn trước trong trường hợp nó nổ tung vào mặt bạn.

$config = get-content .git\config
$url = $config -match " url = (?<content>.*)"
$url = $url.trim().Substring(6)
$url

move-item -v .git .git_old;
git init;
git remote add origin "$url";
git fetch;
git reset origin/master --mixed

0

Cách nhanh chóng nếu bạn có thay đổi trong dự án hiện tại của mình và không muốn mất nó, hãy di chuyển dự án hiện tại của bạn đến đâu đó, sao chép dự án từ github vào thư mục này và thực hiện một số thay đổi và thử cam kết lại. Hoặc chỉ cần xóa repo và sao chép nó một lần nữa, nó đã hoạt động với tôi.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.