如何解决git 2个地方的代码不一致.-Questions et réponses sur le réseau chinois PHP

初始情况是, 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去修改了...
(/ □ )

répondre à tous(3)

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

Avant de tirer origin master, votre b a un commit tel que abcde

# 在b机器上
$ git reset abcde --hard

Retour à ce qu'il était avant b pull
Et comme votre a n'a jamais été retiré, il peut désormais être considéré comme revenu à votre apparence d'origine, à l'exception de la soumission d'un a qui a ajouté une ligne vide

C'est-à-dire que vous devriez être dans le même état maintenant qu'en 2.
A cette époque, votre b est aussi un espace de travail propre (pas de changement non mis en scène)
Si vous êtes convaincu que l'état actuel est bien le même qu'en 2, alors exécutez

sur b

$ git fetch origin
$ git rebase origin/php-v0.0.1

Il vous sera rappelé qu'il y a un conflit, tel que .gitignore
Ouvrez ensuite le fichier .gitignore, résolvez le conflit, puis exécutez

$ git add .gitignore #添加解决了冲突的文件
$ git commit #直接:wq即可

Si quelque chose d'inattendu se produit pendant le processus de rebase, veuillez ne pas opérer à volonté, abandonnez avant git rebase --abort, puis ajoutez des questions

Comme +0

Ajouter une réponse

刘奇2017-04-25 09:05:31 2 plancher

Je ne pense pas que ce soit si compliqué...

A, la dernière mise à jour locale est toujours OK, n'est-ce pas ? Je veux dire, après la dernière poussée de B, A n'a pas tiré, n'est-ce pas ? Si tel est le cas, laissez A push --force directement pour écraser la dernière poussée de B, puis B tirez à nouveau. Ne faites pas d'erreur cette fois, tout ira bien à l'avenir.

Si A a déjà extrait le dernier code (c'est-à-dire erroné), réinitialisez-le localement sur le code initialement correct, puis répétez ce qui précède.

En un mot, l'avantage de la distribution est que quoi qu'il arrive au repo central, les commits souhaités peuvent toujours être trouvés.

Peter_Zhu2017-04-25 09:05:31 1 plancher

Parce que je suis étourdi et que je ne suis pas habitué à la ligne de commande git, je ne donnerai pas de réponse précise.

Je veux juste dire que dans ce scénario, git pull cette commande ne doit pas être utilisée, fetch & rebase est la bonne façon

De plus, la posture d'utilisation de Git est plus problématique

Il y a un problème avec deux personnes développant dans la même branche en même temps. Dans la plupart des cas, chacune devrait jouer dans sa propre branche de fonctionnalités. Ses fonctions inachevées devraient être dans sa propre branche et extraire le code des autres. n'affecte jamais ses propres branches.
Il y a un problème avec un commit de plus de 10 fichiers. Ou d'un point de vue temporel, il y a un problème si le travail de codage qui a pris plus d'une demi-journée n'a pas été soumis

Plutôt que de résoudre le problème de gâcher le code existant (c'est un petit problème qui peut toujours être résolu), il est plus important de vulgariser la bonne posture git au sein de l'équipe

Référence : Un modèle de branchement Git réussi http://www.juvenxu.com/2010/11/28/a-successful-git-branching-model/