Git operations-branch management (2), git operation branch management

Git operations-branch management (2), git operation branch management
Resolve Conflicts

Scenario: Create a new branch feature1 and then add it to the readme.txt file.4 create a branch named feature1And then submit it on the feature1 branch. After submission, switch to the master branch, and then change the last rowcreate a new branch named feature1And submit again. Now, both the master branch and feature1 Branch have new commits respectively:

The structure is as follows:

In this case, we try to merge the two branches,git merge feature1:

The prompt is that the readme.txt file has a conflict (conflict). You need to resolve the conflict before submitting the file. Now let's take a look at the file content:

Git<<<<<<<，=======，>>>>>>>Mark the content of different branches,
Manually modify the conflicting parts and save them:4 create a branch named feature1And then submit and find that the conflict has been resolved:

The branch structure is as follows:

Then you can delete the branch feature1.

Note: When Git cannot automatically merge branches, the conflict must be resolved first. After resolving the conflict, submit it again and merge it.
Use the git log-graph command to view the branch merge graph.

Branch Policy

In actual development, branch management should follow several basic principles:

First of all, the master branch should be very stable, that is, it is only used to release new versions, and usually cannot work on it;
Where can I work? All work is on the dev branch. That is to say, the dev branch is unstable. at a certain time, for example, when version 1.0 is released, the dev branch is merged to the master, release Version 1.0 on the master branch;

Everyone you and your friends work on the dev branch. Everyone has their own branch. You can merge them on the dev branch from time to time.

Therefore, the branch of the team cooperation looks like this:

When merging branches, you can use the-no-ff parameter to merge them in the normal mode. The merged branches have been merged in history, and we can see that they have been merged, however, the merge in the fast forward mode cannot be seen as a merger. However, in this mode, branch information is lost after the branch is deleted. In general, Git uses the Fast forward mode if possible when merging branches ..
If you want to forcibly disable the Fast forward mode, Git will generate a new commit at merge, so that the branch information can be seen from the branch history.

For example, add a row to the feature1 Branch:fast forwardAnd then submit it to the feature1 branch, switch to the master branch, and merge the feature1 branch. Note that the-no-ff parameter indicates that the Fast forward command is disabled.$ git merge --no-ff -m "merge with no-ff" feature1Because this merge creates a new commit, the-m parameter is added to write the commit description.
After the merge, use git log to view the branch history:

$ git log --graph --pretty=oneline --abbrev-commit*   7825a50 merge with no-ff|\| * 6224937 add merge|/*   59bc1cb conflict fixed...

Note:

If you modify the content on the master branch but do not submit it, an error occurs when you switch to another branch: