In this example, how can Git tell if B prime and
B double prime are modified versions of B or
if the users just deleted B and wrote entirely new lines in the same area?
Rather than expending a lot of effort trying to figure this sort of thing out,
Git just notes that the lines are different and goes from there.
So how does Git know whether or not there should be a merge conflict?
Consider the following two examples.
In both cases, we start with two identical copies of the same file.
In the first case,
two different contributors add new functions to the bottom of the files.
These are different functions that don't interact with each other and
have nothing to do with one another.
However, in the second case, two different contributors add
different implementations of the same function with different names.
In the first case, you pretty clearly want both functions to be included, but
in the second situation, you probably only want one version of the function,
probably whichever one is either more memory efficient or
faster, depending on what you're going for.
But Git can't really tell these two options apart.
It would take some pretty sophisticated machine learning to do this.
And this is only one possible scenario.
Making Git smart enough to figure out all the possible cases where you'd want to
auto-merge would be a huge undertaking.
So instead, Git just assumes that if you're merging together two commits that
have changes in the same general area, the authors will want to know about it
and have the chance to figure out for themselves which change to keep.
This decision to ask the user whenever there's any ambiguity at
all does sometimes lead to situations where it seems really obvious to you,
as an expert on the content, how to resolve the conflict.
But Git brings it to your attention anyway.
While this may be annoying, it's significantly better than if Git tried to
guess too often, which could lead to weird conglomerate changes that don't
really make any sense and probably wouldn't compile or run.
في هذا المثال، كيف يوضح Git إذا كانت B prime
وB double prime إصدارات معدلة من B أو
عند قيام المستخدمين بحذف B وكتابة سطور جديدة بالكامل في نفس المساحة؟
،بدلاً من بذل المزيد من الجهد في محاولة معرفة نوعية هذا الأمر
.يذكر Git فقط أن السطور تكون مختلفة، ويبدأ من هناك
وبالتالي، كيف يعرف Git بحدوث تعارض دمج أم لا؟
.فكروا في المثالين التاليين
.في كلتا الحالتين، نبدأ بنسختين متطابقتين من الملف نفسه
،في الحالة الأولى
.يضيف مساهمين مختلفين دوال جديدة إلى الجزء السفلي من الملفات
،وتكون دوال مختلفة لا تتفاعل مع بعضها البعض
.ولا تفعل أي شيء مع بعضها البعض
ومع ذلك، في الحالة الثانية، يضيف مساهمين مختلفين
.تنفيذين مختلفين لنفس الدالة بأسماء مختلفة
في الحالة الأولى، ربما تريدون تضمين كلا الدالتين بوضوح، ولكن
،في الحالة الثانية، ربما تريدون إصدار واحد من الدالة فقط
ربما الإصدار الذي يكون أكثر فعالية من حيث الذاكرة
.والسرعة تبعًا لما تحاولون الحصول عليه
.ولكن Git لا يستطيع ذكر هذين الخيارين على حدة
.يتطلب الأمر جهاز متطور إلى حد ما للقيام بذلك الإجراء
.وهذا هو السيناريو المحتمل الوحيد
جعل Git ذكيًا بدرجة كافية لمعرفة كل الحالات المحتملة
.التي سيمثل إجراء الدمج التلقائي بها مهمة شاقة
وبالتالي، بدلاً من ذلك، يفترض Git أنكم إذا كنتم
تقومون بدمج تثبيتين يتضمنا تغييرات في نفس المساحة
.العامة، فإن المؤلفين يريدون معرفته، وتتاح لهم الفرصة لمعرفة التغيير المراد الاحتفاظ به بأنفسهم
هذا القرار لمطالبة المستخدم عندما يكون هناك غموض
،يؤدي أحيانًا إلى حالات يبدو واضحًا خلالها بالنسبة لكم
.كخبراء في المحتوى، كيف يمكنكم حل التعارض
.وبالتالي Git تشير انتباهكم إلى ذلك بأي حال
برغم أن ذلك قد يكون مزعجًا، ولكن يكون أفضل مما إذا حاول Git
تخمينه كثيرًا، مما قد يؤدي إلى تغييرات مختلطة
.غريبة لا تبدو منطقية بالفعل، وربما لن يتم تجميعها أو تشغيلها
이 예제에서 Git 은 어떻게 B' 와 B'' 이
B 에서 변경된 것인지 아니면 사용자가 B 를 지우고
같은 자리에 같은 코드를 썼는지를 알 수 있을까요?
이를 알아내려고 많은 노력을 하는 대신에
Git 은 단순히 코드가 다르다는 것에 주목합니다
그럼 Git 은 어떻게 머지할 때 충돌이 나는지 판단을 할까요?
다음 두 예를 생각해봅시다
두 경우 모두 같은 파일의 복사본으로 시작합니다
첫 번째 경우는
둘 모두 파일의 끝에 새로운 함수를 추가합니다
두 함수는 서로 다르고 서로 관련되거나
같이 작동하지도 않습니다
두 번째 경우는
같은 기능의 함수를 다른 방식으로 구현한 경우입니다
첫 번째 경우는 두 함수 모두 확실히 포함 되야 하지만
두 번째 경우는 둘 중 하나만 있으면 됩니다
더 효율적이고 빠른
함수를 선택하려고 합니다
하지만 Git 은 이 둘을 구분할 수 없습니다
매우 복잡한 머신러닝이 필요할 것입니다
단순히 하나의 시나리오일 뿐입니다
Git 을 자동 머지를 위해 모든 가능성을 구분할 수 있게
만드는 것은 매우 큰 일이 될 것입니다
대신에, Git 에서는 두 커밋을 머지할 때
같은 지역에 변경이 있다면 작성자에게 어떤 변경을
남길지를 선택할 기회를 줍니다
모호한 점이 있을 때마다 사용자에게 물어보는 것은
내용에 대한 전문가로서 충돌을 해결하는 방법을
이끌어 내도록 하는 상황을 보일 수도 있습니다만
어쨌거나 Git 은 이 문제를 가져오게 됩니다
조금 귀찮을 수도 있지만 Git 이 추측해서
전혀 의미 없거나 컴파일과 실행이 안되는
코드가 만들어지는 것보다 더 낫습니다
Neste exemplo, como o Git sabe se B´
e B´´ são versões modificadas de B
ou se o usuário apenas excluiu B e escreveu linhas totalmente novas na mesma área?
Em vez de ficar se esforçando para tentar entender isso,
Git só nota que as linhas são diferentes a parte daí.
Então como o Git sabe se deve ou não haver um conflito de fusão?
Considere os dois exemplos a seguir:
Em ambos os casos, começamos com duas cópias idênticas do mesmo arquivo.
No primeiro caso,
dois colaboradores novos adicionam funções novas ao final dos arquivos.
São funções diferentes que não interagem entre si
e não têm nada a ver uma com a outra.
No entanto, no segundo caso, dois colaboradores diferentes
adicionam implementações da mesma função com nomes diferentes.
No primeiro caso, você claramente quer que ambas as funções sejam incluídas,
mas na segunda situação, você provavelmente só quer uma das ocorrências da função,
muito provável que seja a que tenha memória mais eficiente
ou mais rápida, dependendo do que você estiver procurando.
Mas o Git não consegue fazer essa distinção.
Seria preciso uma recurso de aprendizado de máquina muito sofisticado para fazer isso.
E este é apenas um dos possíveis cenários.
Tornar o Git inteligente o suficiente para entender todos os casos possíveis
em que você gostaria que houvesse uma fusão automática seria uma tarefa absurda.
Então, em vez disso, o Git apenas supõe que você está fundindo dois commits
que têm alterações na mesma área geral. Os autores querem saber disso
e ter a chance de entender por si próprios quais alterações manter.
Essa decisão de perguntar ao usuário sempre que houver qualquer ambiguidade
às vezes leva a situações em que tudo parece extremamente óbvio para você,
um especialista no conteúdo, como resolver o conflito.
Mas o Git chamará sua atenção para isso de qualquer maneira.
Mesmo que seja irritante, é bem melhor do que se o Git tentasse adivinhar com frequência,
o que poderia levar a estranhas alterações aglomeradas
que na verdade não fazem sentido e provavelmente haveria falha na compilação e execução.
在这个例子中 Git 要如何区分 B′ 和 B″
是 B 的修改版本
还是只是用户删除了 B 然后在同一区域写的全新行呢？
Git 不会在这种事上花费大量时间
只是知道这些行是不同的 然后 从不同之处着手
那么 Git 如何知道 是否会有合并冲突？
思考一下下面两个例子
在这两种情况下 我们首先使用 同一文件的两个相同拷贝
第一种情况中
两个不同的贡献者 在文件底部添加了新函数
这些函数并不相同 彼此之间没有交互
也没有任何关系
而在而第二种情况中 两个不同的贡献者
添加的是同一个函数的 不同实施方法 名称也不同
在第一种情况中 你很清楚要添加两个函数
但在第二情况中 你可能只想要一种版本的函数
哪一种的内存更高效、更快
取决于你用来做什么
但 Git 无法区分这两个选项
这需要一些相当复杂的机器来学习如何区分
这只是一种可能的场景
要使 Git 能够算出你想自动合并的所有情况
将是一个非常艰巨的任务
所以 Git 只是假设你要合并的
是在同一区域进行更改的两个提交 作者将会希望了解
并有机会算出要保留哪一个更改
这种询问用户是否有含糊之处的决策
有时会引导作为该内容专家的你 更清晰地知道
如何解决冲突
Git 让你注意到了这一点
这可能很烦人 但是 总好过 Git 过于频繁的猜测
这种猜测可能会导致多次更改
而这些更改可能根本没有任何意义 甚至可能不会编译或运行