简体繁体 English

如何合并在GIT中修改的文件

[英]How to merge files which are modified in GIT

原文 2015-03-26 12:41:53 1 2 git/ merge

I am new to Git versioning tool. 我是Git版本控制工具的新手。 Previously I was using SVN. 以前我使用的是SVN。

If we have a file a.php which has some modifications on the 50th line number and there are changes in the 500th line number in another branch for the same file which has been committed. 如果我们有一个文件a.php，它对第50行号进行了一些修改，而对于已提交的同一文件，另一个分支中第500行号有变化。 How do we merge the two branches without stashing the changes or using git checkout --patch ? 如何合并两个分支而不存储更改或使用git checkout --patch？

In SVN we just used to execute one command 'svn update a.php'. 在SVN中，我们只是用来执行一个命令“ svn update a.php”。 Whereas here we will have to execute three commands. 而在这里，我们将必须执行三个命令。 git stash, git merge branchname, git stash apply. git stash，git merge分支名称，git stash适用。

Thanks in advance. 提前致谢。

2 个解决方案

In Git, you always commit before you merge. 在Git中，您总是在合并之前提交。 The idea is to never have any modified files in the workspace when you merge. 这样做的目的是在合并时在工作空间中永远不要有任何修改过的文件。 This is one of the main features over SVN: In Subversion, your uncommitted changes would be merged with work by someone else. 这是SVN的主要功能之一：在Subversion中，您未提交的更改将与其他人的工作合并。 The result of that is sometimes unpredictable. 其结果有时是不可预测的。 The most predictable thing is that it's always a lot of work to sort out the mess which svn update leaves behind. 最可预见的是，清理svn update留下的混乱总是很多工作。

In Git, a branch is very, very cheap. 在Git中，一个分支非常非常便宜。 It's so cheap in fact that you hardly notice when you create one. 实际上，它是如此便宜，以至于您在创建一个时几乎不会注意到。

So you always commit everything. 因此，您始终会付出一切。 Then you say "I want to merge with that commit over there" (usually by giving Git the name of the branch which contains the commit). 然后，您说“我想与那边的提交合并”（通常通过给Git命名包含提交的分支的名称）。

Something goes wrong? 出问题了吗？ No problem, Git can restore the previous state without fail (unlike Subversion) since the previous state was committed to the repository. 没问题，由于先前的状态已提交到存储库，因此Git可以毫无故障地还原先前的状态（与Subversion不同）。

Now there are people who believe that linear history is so valuable that they feel they have to sacrifice this feature. 现在有些人认为线性历史非常有价值，以至于他们认为必须牺牲这一功能。 This is usually not true or causes more problems that it solves. 这通常是不正确的，否则会导致更多问题得以解决。 It's especially dangerous to do when you're starting with Git. 当您开始使用Git时，这样做特别危险。 rebase is a complex and sometimes dangerous operation and not for beginners. rebase是一项复杂且有时很危险的操作，并不适合初学者。

That's why I suggest to start with a simple workflow: 因此，我建议从简单的工作流程开始：

Commit your work. 投入你的工作。
Pull (which will automatically merge) 拉（将自动合并）
If something goes wrong: Undo (see below) 如果出现问题：撤消（请参见下文）
Run your tests 运行测试
When everything looks good, push 当一切看起来不错时，按

Related: 有关：

If you currently are on one branch with a commit with changes to the 50th line, and you have a parallel branch with a commit with changes to the 500th line, and you want to merge those 2 branches, you run git merge <parallel branch> . 如果您当前在一个分支上进行了第50行更改的提交，并且在并行分支上进行了对500行更改的提交，并且想要合并这两个分支，则可以运行git merge <parallel branch> 。 This effectively merges the parallel branch into your current branch. 这有效地将并行分支合并到您的当前分支中。

As the changes in the 2 commits are on separate lines in the file, then the merge will be automatically done by Git without any conflicts. 由于两次提交的更改位于文件的单独行中，因此合并将由Git自动完成，而不会发生任何冲突。