検索

ホームページ  >  に質問  >  本文

如何解决git 2个地方的代码不一致.

初始情况是, a和b的代码库是完全相同的.

1, a修改了代码.然后成功push到 bitbucket
2, a做了更改是: 程序中的目录app/storage/sessions/刚开始没有加入到.gitignore中,所以a在.gitignore中加了这个目录.其它的是一些程序的代码.
3, b本身有代码,但没有修改.因为a更新了,所以b进行pull操作,可能是因为.gitignore冲突,git有提示到git reset --hard这一句,以为是会重置(reset这英语),就选了另一项(忘了选了什么了),然后进行平常的pull,commit,提示pull到bitbucket成功了,但看代码却没有看到a所做的更改.没在意,b就继续修改代码,push到远程.b这边提示这个.

b以为自已看懂了,选择了
$ git add --ignore-removal app/storage/sessions/

然后..上bitbucket一看,发现刚才a所做的更改全被删除了..

例如:像图片中这些是a加入的东西, 还有很多其他的代码,...现在全被删除掉了..

怎么恢复a成功push的更改,同时也保留b的这次更改呢? a的commit有160个文件改动,b的也有60多...除了a和b2人商讨根据代码一条条的对照思路进行恢复,有没有比较好的方案呢? 谢谢啦 ...


更新:

按照@nightire的回答, a这边进行了如下操作

# git add .
# git commit -m "big wrong! for last your git-commits"
On branch php-v0.0.1
Your branch is up-to-date with 'origin/php-v0.0.1'.

nothing to commit, working directory clean

所以,a修改了一个文件,加了一个空行,然后重新# git push --force orgin php-v0.0.1:php-v0.0.1

接着,b这边进行如下操作

$ git pull origin php-v0.0.1:php-v0.0.1
Password for 'https://Deloz@bitbucket.org':
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 4), reused 2 (delta 0)
Unpacking objects: 100% (6/6), done.
From https://bitbucket.org/deloz/xxxxx
 ! [rejected]        php-v0.0.1 -> php-v0.0.1  (non-fast-forward)
 + c344522...14bd65e php-v0.0.1 -> origin/php-v0.0.1  (forced update)

好像b又操作错了,这分支好像不对呀,然后b又来了一次不加参数了pull,如下

$ git pull
Password for 'https://Deloz@bitbucket.org':
Merge made by the 'recursive' strategy.
 app/database/migrations/xxxxxx.php | 1 +
 1 file changed, 1 insertion(+)

此时,b这边仍然没有a加入的文件和a之前(b出错前,a修改并push成功的代码)的修改.(这次a是加了一个空行,b这边也成功反映出来了.)...


再更新:

根据大家的看法和方案
a操作

# git log --pretty=oneline
14bd65ee1b14c1f06be98b22bc6cb5feb2039656 big wrong! for last your git-commits
3c96695b53f7d4e8dd78c9025044cea1d4cc0472 这个是正确的时候a所push的
00f0cdd6b8861d64a7930b823f552888edebdc11 xxxxxxxxxx
668fde30ad1d5d76b550f572ba6b64ae14a1e715 xxxxxx
8a80bb0eb9387db68119bbd7e0d15677ed7aa1f1 xxxxx
7ca8599be1ceb1dde6766315543209bf1bb761ce xxxxx^
bba184c4f324ed99b3fb580c103aba3505a688a5 xxxxxxxxx
458182037cfa54b8447b617c119d134ada250462 xxxxxxxxx
0029b46ac999f2c4d59c8cfb194ed1c2653fa1f4 xxxxxxn

b使用了git revert commit,代码没回滚到正确的commit去..应该是用错了..

$ git log --pretty=oneline
06661f005bc306796d2101633f68c2d01cd6bac3 re push (b push上来的)
3e34c6f8c177c67d487c7858720ac383e77738e2 Revert "Revert "big wrong! for last you  (b push上来的)
bcf07a9836aaaa9bdd505094b0859c13322f4519 Revert "big wrong! for last your git-co (b push上来的)
885c117de5ef67f430e0d3f8b0b1647a1cd14ee8 Merge branch 'php-v0.0.1' of https://bi (b push上来的)
14bd65ee1b14c1f06be98b22bc6cb5feb2039656 big wrong! for last your git-commits(a加空行后 push上来的)
c344522e2cba0e85e4b14393d596b992d47f1821 add column to table  (b push上来的)
3c96695b53f7d4e8dd78c9025044cea1d4cc0472 这个是正确的时候a所push的
00f0cdd6b8861d64a7930b823f552888edebdc11 xxxxxxxxxx
668fde30ad1d5d76b550f572ba6b64ae14a1e715 xxxxxx
8a80bb0eb9387db68119bbd7e0d15677ed7aa1f1 xxxxx
7ca8599be1ceb1dde6766315543209bf1bb761ce xxxxx^
bba184c4f324ed99b3fb580c103aba3505a688a5 xxxxxxxxx
458182037cfa54b8447b617c119d134ada250462 xxxxxxxxx
0029b46ac999f2c4d59c8cfb194ed1c2653fa1f4 xxxxxxn

接着
a执行

//备份一下当前a的分支
# git branch php_backup

//把a的分支回滚到 3c96695b53f7d4e8dd78c9025044cea1d4cc0472  因为上一次操作是 push --force了...
# git reset --hard 3c96695b53f7d4e8dd78c9025044cea1d4cc0472
HEAD is now at 3c96695 change some views

//删除远程的bitbucket上的分支
# git push origin :php-v0.0.1
Password for 'https://deloz@bitbucket.org':
To https://deloz@bitbucket.org/deloz/xxx.git
 - [deleted]         php-v0.0.1

//把正确的3c96695b53f7d4e8dd78c9025044cea1d4cc0472, push到远程bitbucket上
# git push origin php-v0.0.1
Password for 'https://deloz@bitbucket.org':
Counting objects: 256, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (220/220), done.
Writing objects: 100% (256/256), 785.09 KiB | 0 bytes/s, done.
Total 256 (delta 64), reused 158 (delta 26)
To https://deloz@bitbucket.org/deloz/xxx.git
 * [new branch]      php-v0.0.1 -> php-v0.0.1

然后, 根据@Guang Chen的方法, b操作

//备份一下B的分支
$ git branch php_bbbb
//把b的分支回滚到 3c96695b53f7d4e8dd78c9025044cea1d4cc0472
$ git reset --hard 3c96695b53f7d4e8dd78c9025044cea1d4cc0472
$ git fetch origin
$ git rebase origin/php-v0.0.1

//看一下log, b和a的一样的状态了.
$ git log --pretty=oneline
3c96695b53f7d4e8dd78c9025044cea1d4cc0472 这个是正确的时候a所push的
00f0cdd6b8861d64a7930b823f552888edebdc11 xxxxxxxxxx
668fde30ad1d5d76b550f572ba6b64ae14a1e715 xxxxxx
8a80bb0eb9387db68119bbd7e0d15677ed7aa1f1 xxxxx
7ca8599be1ceb1dde6766315543209bf1bb761ce xxxxx^
bba184c4f324ed99b3fb580c103aba3505a688a5 xxxxxxxxx
458182037cfa54b8447b617c119d134ada250462 xxxxxxxxx
0029b46ac999f2c4d59c8cfb194ed1c2653fa1f4 xxxxxxn


$ git status
On branch php-v0.0.1
Your branch is up-to-date with 'origin/php-v0.0.1'.

nothing to commit, working directory clean

剩下的就是分支php_bbb里边的不同代码...
使用git diff php-v0.0.1 php_bbbb >> 11.txt ,让b去修改了...
(/ □ )

黄舟黄舟2772日前1036

全員に返信(3)返信します

  • 阿神

    阿神2017-04-25 09:05:31

    オリジンマスターをプルする前に、bにはabcdeなどのコミットがあります

    リーリー

    プルする前の状態に戻りました
    そして、あなたの a は一度もプルされていないので、空白行を追加する a の送信を除いて、元の外観に戻ったと考えることができます

    つまり、今のあなたは2のときと同じ状態になっているはずです。
    現時点では、あなたの b もクリーンなワークスペースです (ステージングされていない変更はありません)
    現在の状態が確かに 2 と同じであると確信できる場合は、b で

    を実行します。 リーリー

    この時点で、.gitignore
    などの競合があることが通知されます。 次に、.gitignore ファイルを開いて競合を解決し、

    を実行します。 リーリー

    リベースプロセス中に予期せぬことが起こった場合は、気軽に実行せず、git rebase --abort までに諦めてから質問を追加してください

    返事
    0
  • 怪我咯

    怪我咯2017-04-25 09:05:31

    それほど複雑ではないと思います...

    A、最新のローカルアップデートはまだ大丈夫ですよね?つまり、B が最後に押した後、A は引かなかったのですよね?この場合は、A が --force を直接プッシュして B の最後のプッシュを上書きし、次に B が再度プルします。今回は間違えないでください。将来は大丈夫です。

    A がすでに最新の (つまり間違った) コードを取得している場合は、それをローカルで元の正しいコードにリセットし、上記の手順を繰り返します。

    一言で言えば、分散の利点は、中央リポジトリに何が起こっても、必要なコミットが常に見つかることです。

    返事
    0
  • 天蓬老师

    天蓬老师2017-04-25 09:05:31

    私はめまいがしていて git コマンドラインにあまり慣れていないので、具体的な答えはしません。

    私が言いたいのは、この状況ではgit pull这条命令就不应该用,fetch & rebaseが正しい方法であるということです

    さらに、Gitの利用姿勢にはさらに問題があります

    • 2 人が同じブランチで同時に開発する場合、問題が発生します。ほとんどの場合、未完成の関数はそれぞれのブランチで実行する必要があり、他の人のコードをプルする必要があります。自身のブランチには影響しません。
    • 10 個を超えるファイルのコミットに問題があります。あるいは、時間的に見て、半日以上かかったコーディング作業が提出されなかったら問題があります

    既存のコードを台無しにする問題を解決すること(これはいつでも解決できる小さな問題です)を解決することと比較して、正しい Git の姿勢をチーム内に浸透させることがより重要です

    参考: 成功した Git ブランチング モデル http://www.juvenxu.com/2010/11/28/a- success-git-branching-model/

    返事
    0
  • キャンセル返事