Git five common problems and Solutions

<img src="" width="600" height="354">

1, Delete ignored files on remote warehouse

For various reasons, some files that should have been ignored were submitted to the remote warehouse by mistake. So how do we delete these files?

Take the missubmission of the. idea directory as an example, we can handle it through the following steps:

1) We should first clear the. idea file in the staging area and execute the command

# -r means to delete a file or folder -- cached only clears the temporary storage area, not the working area
git rm -r --cached .idea

2) In the. gitignore file, add the file you want to ignore.


After submission, the. idea related files will be deleted

git commit -m 'Submit information'
git push

The difference between git rm and git rm --cached

git rm: deletes files from both the workspace and the staging area. That is, the local files have also been deleted.

git rm --cached: deletes files from the staging area. However, the local file still exists, but you don't want this file to be version controlled.

Obviously, the. idea file above cannot be deleted in my own workspace. I can only delete the staging area, so I need to add -- cached

As shown in the figure

<img src="" width="400" height="438">

2, Half of the code development, there are new tasks

When you are developing a requirement in barabarabara, you are only half done. At this time, you receive another requirement that needs to be developed urgently. You can put the previous requirement first. You don't want to submit git commit to the repository, that is, there are some code in the workspace or staging area that you don't want to submit to the repository.

What should we do at this time?

You can use the git stash command to solve this problem.

1) First, the changes in the workspace and staging area are stored on the stack.

# -U means that the newly added files in the workspace will also be stored. If you do not add u, only the modifications of the existing files in the workspace will be stored
git stash save -u "demand a Only half done"

In this way, the workspace and staging area are clean.

We can also view the list of stash in the stack. (since we only stored git stash once, there is only one stash in the stack)

$ git stash list
stash@{0}: On main: demand a Only half done

You can also view what is stored in the stash

git stash show

2) Then, in the current dev branch, requirements b can be completed first

If the requirement b has been developed, submit it to the version library.

git add .
git commit -m "demand b Completed"
# dev branch pushed to remote
git push origin dev

3) Finally, we pop up the stash in the stack and apply it to the current workspace

git stash pop

Continue to complete the unfinished work in requirement a. If the requirement a is also completed, it is also submitted to the version library.

git add .
git commit -m "demand a Also complete"
# dev branch pushed to remote
git push origin dev

That's it.

3, git pull code conflict

When you submit the code and want to pull the code first, you find that

$ git pull
error: Your local changes to the following files would be overwritten by merge:
Please commit your changes or stash them before you merge.

Obviously, the code you modify locally conflicts with that submitted by others. The file tells you

How to solve it?

1) Store the local code first

git stash

2) Then pull the remote code

$ git pull
Updating 5b82c67..3d844c3
 src/main/java/com/open/demo/beans/ | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

It is found that there are no errors reported and can be pull ed down normally.

3) Finally, release the locally stored code

$ git stash pop
Auto-merging src/main/java/com/open/demo/beans/
CONFLICT (content): Merge conflict in src/main/java/com/open/demo/beans/

Release it. It also tells you that there is a conflict. Then manually resolve the conflict and you can submit it normally.

4, Merge branch conflicts

The above problem is the conflict caused by pulling code from the same branch. Here, the conflict occurs when two branches are merged.

For example, now there are two branches. You submit a file after dev modifies it, and the master branch changes the same file, and the same file is submitted successfully. At this time, when you merge dev into the master, you find that there is no merging and conflict. This problem is also very common in practical development.

Here, a conflict occurs when the dev is merged into the master

1) . switch from dev to master branch

git checkout master

2) . merge dev

git merge dev

If there is a conflict, it will tell you which files conflict

$ git merge dev
Auto-merging src/main/java/com/open/demo/beans/
CONFLICT (content): Merge conflict in src/main/java/com/open/demo/beans/
Automatic merge failed; fix conflicts and then commit the result.

Then you just need to find the current conflict file and resolve the conflict.

<<<<<<< HEAD
    private final   long serialVersionUID = -1206184202179044275L;
    private  long serialVersionUID = -1206184202179044275L;
>>>>>>> dev

After modification, resubmit it.

5, master modifies the code and pushes it to dev

When you modify the code in the master, you need to push the modified code to the dev remote branch

1) . on the master

   git add .
   git commit -m "Description of this submission"

2) , switch to dev branch

git checkout dev

3) . merge master

git merge master

4) . push to main warehouse

git push

If the dev branch commits the code, it needs to add and commit again.

Statement: if the official account needs to be reprinted, the trouble is that the head statement is transferred to the official account: the backend meta universe. Respect the fruits of the author's hard work. At the same time, you can also ask me for the original markdown and the original picture of the article. Reprint is prohibited in other cases!

This article is composed of blog one article multi posting platform OpenWrite release!

Tags: Java

Posted on Wed, 01 Dec 2021 19:20:21 -0500 by mattdarnold