Error your local changes to the following files would be overwritten by merge readme md - Исправление ошибок и поиск оптимальных решений проблем

The error message “Your local changes to the following files will be overwritten by merge” occurs in Git version control mechanism. This error occurs if you have modified a file which also has modifications in the remote repository.

Git Error: Your local changes to the following files will be overwritten by merge

This error message is avoided IF there are no uncommitted files that also have modifications in the remote repository. When experiencing this message, it is best to consult your other team members and ask for their opinion. Whether you want to merge your local changes or keep the version present in the repository, it is best to keep everyone on board.

What are repositories? What are push and pull in Git?

A repository is a kind of storage for code which is constantly modified and obtained by team members through the GitHub version control mechanism. A ‘Pull’ means that you are pulling the latest version of the repository onto your local storage/IDE (Integrated Development Environment) such as Pycharm etc.

After a Pull, you make changes to the code or add more features. Once you are done, you ‘Push’ the code onto the repository so changes are saved and additions are made. The code gets accessible to other people as well.

If you are new to Github version control, it is recommended that you go through all the basics first. In this article, we assume that you already have basic knowledge and know all the ins and outs.

The resolution of this error message depends on what you want to do. You can discard your local changes and pull the ones in the repository or you can save your local changes into a stash and pull the version from the repository. It all depends on your preference.

Hence, we recommend that you consult with your team members and make sure that you all are on the same page before moving forward. If you commit wrongly or push the wrong version, it could affect the entire team.

Method 1: Forcing a pull to overwrite local changes

If you don’t care about the changes done locally and want to obtain the code from the repository, you can force a pull. This will overwrite all the local changes done on your computer a duplicate copy of the version in the repository will appear.

Execute the following commands in your IDE:

git reset -- hard

git pull

This will instantly destroy all your local changes so make sure that you know what you are doing and don’t need your local changes.

Method 2: Keeping both changes (local and from the repo)

If you want to keep both changes (changes done locally and changes present in the repository), you can add and commit your changes. When you pull, there will obviously be a merge conflict. Here you can use the tools in your IDE (such as Difftool and mergetool) to compare the two pieces of code and determine which changes to keep and which to remove. This is the middle way; no changes will be lost until you manually remove them.

git add $the_file_under_error

git commit

git pull

When you get a merge conflict, pop those conflict resolving tools and check line by line.

Method 3: Keeping both changes BUT not committing

This situation happens from time to time where developers are not ready to commit because there is some partly broken code which you are debugging. Here we can stash the changes safely, pull the version from the repository, and then unstash your code.

git stash save --keep-index

git stash

git pull

git stash pop

If there are some conflicts after you pop the stash, you should resolve them in the usual way. You can also use the command:

git stash apply

instead of pop if you are not ready to lose the stashed code due to conflicts.

If merge doesn’t seem like a viable option for you, consider doing a rebase. Rebasing is the process of moving or combining a sequence of commits to a new base commit. In the case of rebasing, change the code to:

git stash

git pull --rebase origin master

git stash pop

Method 4: Make changes to ‘specific’ parts of your code

If you want to make changes to specific parts of the code and don’t want to replace everything, you can commit everything that you don’t want to overwrite and then follow method 3. You can use the following command for the changes which you want to overwrite from the version present in the repository:

git checkout path/to/file/to/revert

git checkout HEAD^ path/to/file/to/revert

Also, you need to make sure that the file is not staged via:

git reset HEAD path/to/file/to/revert

Then proceed with the pull command:

git pull

This will then attempt at fetching the version from the repository.

Kevin Arrows

Kevin is a dynamic and self-motivated information technology professional, with a Thorough knowledge of all facets pertaining to network infrastructure design, implementation and administration. Superior record of delivering simultaneous large-scale mission critical projects on time and under budget.

Источник

The setup

Suppose you are working on a software project with one other person. You and your partner share a repository on GitHub; you have a local copy of the repo on your laptop, and your partner has a local copy on their laptop.

Initially, there is a file named README.md in the repo, your local copy, and your partner’s local copy; and all three versions are identical.

Now suppose you and your partner want to revise this file. There are several ways you might collaborate:

(1) Time sharing: You could talk to each other and agree that you will not edit the same file at the same time. Instead, one of you will edit the file in your local copy, push the change to the repo, and then tell your partner that you are done. The other partner will pull the modified file, make additional changes, and then push them back to the repo.

(2) Space sharing: You could work on separate files at the same time. Each of you could edit their own files, push changes to the repo, and pull the other partner’s changes from the repo.

(3) [NOT RECOMMENDED] Work in branches: Before you start making changes, you could create a branch, push changes to the branch, and then work on merging the branches in the future.

(4) [NOT RECOMMENDED] Work on the same files, in the same branch, at the same time.

For people who are relatively new to Git, working on relatively small projects, and working part time, we STRONGLY recommend choosing option (1) or (2).

People with more Git experience will try to make you feel bad about these options, and they will badger you into choosing option (3). Ignore them.

However, even if you intend to choose (1) or (2), you are likely to make a mistake at some point and accidentally choose (4). In that case, you are likely to encounter a merge conflict.

What is a merge conflict?

In this document, we use “merge conflict” to refer to any scenario where you and your partner have changed the same file and you need to reconcile your changes.

With Jupyter notebooks, in particular, you should be aware that running a notebook generally modifies the contents, which can cause a merge conflict.

We’ll consider two scenarios, depending on whether the change you have made has been committed.

Scenario I: Local change, not committed

Suppose your partner has modified README.md and pushed the change to the repo. In your local copy, you have also modified README.md, but you have not yet committed the change. Let’s see what happens, and what you can do to resolve it.

1) Clone a repo on GitHub to make a local copy. If you have a partner, have them clone a local copy, too.

2) Tell your partner to edit README.md, commit the change, and push it to the repo.
Or, if you are working alone, you can simulate the same effect by viewing the repo on GitHub, editing README.md,
making a small change, and committing the change.

3) In your local copy, edit README.md and save the change but don’t commit it. If you run git status, you should see:

4) If you run git pull, you should see:

error: Your local changes to the following files would be overwritten by merge:
	README.md
Please, commit your changes or stash them before you can merge.

This is a merge conflict. There are several ways you might proceed, depending on what changes you and your partner have made.

A: If you don’t care about the changes you have made in your local copy, the easiest thing to do is delete the file that would be overwritten by the merge. Try this:

$ rm README.md
$ git pull

The git pull should succeed now: it should pull the modified version of README.md from the repo,
along with any other changes that are in the repo but not in your local copy.

B: If you don’t care about the changes your partner made and you want to replace them with your changes, the easiest thing to do is upload your modified file to GitHub. View your repo in a web browser, navigate to the directory that contains the conflicted file, and press the “Upload files” button. Navigate to your modified file and upload it. Now delete your local copy of the file and git pull again.

B2: Again, if you don’t care about the changes your partner made and you want to replace them with your changes, you can

$ mv README.md README.md.mine
$ git pull
$ mv README.md.mine README.md

And then add README.md, commit and push.

C: If there are changes in both versions that you want to keep,
the easiest thing to do is merge them by hand. You can do that by running

$ mv README.md README.md.mine
$ git pull
$ meld README.md README.md.mine

meld is a graphical program that compares files and makes it easy to merge changes from the two of them until you have what you want.
If you don’t already have it installed, run

$ sudo apt-get install meld

Or use whatever text editor you like to move the changes you want to keep from README.md.mine to README.md.

Then add, commit, and push the merged version of README.md as usual.

Scenario II: Local change, committed

Suppose your partner has modified README.md and pushed the change to the repo.
In your local copy, you have also modified README.md, and you have committed the change.
Let’s see what happens, and what you can do to reconcile it.

1) Clone a repo on GitHub to make a local copy. If you have a partner, have them clone a local copy, too.

2) Tell your partner to edit README.md, commit the change, and push it to the repo. Or, if you are working alone, you can simulate the same effect by viewing the repo on GitHub, editing README.md, making a small change, and committing the change.

3) In your local copy, edit README.md, save the change, and commit it. If you run git status, you should see:

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

4) Run git push. You should see

! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/AllenDowney/blair-walden-project.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

Before you can push your changes to the repo, you have to pull the changes from the repo, resolve any conflicts,
and then push your changes back to the repo.

5) Run git pull. You should see

Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

This is the first example we have seen that is really a merge conflict in the sense that Git is aware that there is a conflict.
If you run git status, you should see

6) Edit README.md. You will see that Git has combined the changes from the repo and your local copy:

<<<<<<< HEAD
text you added to your local copy
=======
text your partner pushed to the repo
>>>>>>> 98663bb97c1053ed8cc0cc3961a16972a2656e4f

In this example, HEAD refers to the most recent commit in your local copy,
and the long hexadecimal string refers to the commit in the repo.

You can use any text editor to edit this file and resolve the conflict as you see fit. Save the resolved file.

Now you should be able to add, commit, and push the resolved file.

7) As an alternative to Step 6, you can use git mergetool. First, configure git to use meld,
rather than whatever inchoate beast from the depths it uses by default:

$ git config merge.tool meld

Then run git mergetool. You should see:

Merging:
README.md

Normal merge conflict for 'README.md':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (meld):

If you hit return, it should launch meld and show you three versions of your file.
Edit until the local version is what you want, then add, commit, and push it.

Источник

Содержание

How to fix Git Error ‘Your local changes to the following files will be overwritten by merge’
What are repositories? What are push and pull in Git?
How to fix ‘Your local changes to the following files will be overwritten by merge’?
Method 1: Forcing a pull to overwrite local changes
Method 2: Keeping both changes (local and from the repo)
Method 3: Keeping both changes BUT not committing
Method 4: Make changes to ‘specific’ parts of your code
Как правильно сделать слияние чужих и своих изменений?
Git Your local changes to the following files would be overwritten by merge Solution
Your local changes to the following files would be overwritten by merge
Find Your Bootcamp Match
An Example Scenario
The Solutions
Conclusion
Git FAQ
Frequently asked questions around Git and Version Control.
How do I force git pull to overwrite local files?
Step 1: Cleaning Up the Working Copy
a) Saving Local Changes on a Stash
b) Discarding Local Changes
Step 2: Pull Again
Auto-Stashing in Tower
Learn More
Get our popular Git Cheat Sheet for free!
About Us

How to fix Git Error ‘Your local changes to the following files will be overwritten by merge’

Git Error: Your local changes to the following files will be overwritten by merge

What are repositories? What are push and pull in Git?

If you are new to Github version control, it is recommended that you go through all the basics first. In this article, we assume that you already have basic knowledge and know all the ins and outs.

How to fix ‘Your local changes to the following files will be overwritten by merge’?

Method 1: Forcing a pull to overwrite local changes

Execute the following commands in your IDE:

This will instantly destroy all your local changes so make sure that you know what you are doing and don’t need your local changes.

Method 2: Keeping both changes (local and from the repo)

When you get a merge conflict, pop those conflict resolving tools and check line by line.

Method 3: Keeping both changes BUT not committing

If there are some conflicts after you pop the stash, you should resolve them in the usual way. You can also use the command:

instead of pop if you are not ready to lose the stashed code due to conflicts.

Method 4: Make changes to ‘specific’ parts of your code

Also, you need to make sure that the file is not staged via:

Then proceed with the pull command:

This will then attempt at fetching the version from the repository.

Источник

Как правильно сделать слияние чужих и своих изменений?

Please, commit your changes or stash them before you can merge.

Что в этой фразе не понятного?

Вариант 1. — Делаете коммит, а котом git pull и оно вам предложит смержить.
Вариант 2. — Делаете git stash (прячет все незакомиченые локальные изменения); затем git pull; затем git stash pop, а дальше мержите.

Вообще есть третий вариант (на будущее) — создаете локально еще одну ветку, в ней работаете, а потом делаете git pull в основной ветке (точнее в той, от которой вы отпочковались) и мержите с ней свою ветку. (опять же, можете сделать stash, затем «отпочковаться», затем слить изменения с репозитория и потом stash pop в свою ветку, а затем мержитесь, когда надо, с той веткой, откуда отпочковались).

хочу закоммитить изменения в репозиторий, перед этим делаю git pull

Тут у вас есть несколько проблем:
1. команда git pull это на самом деле алиас для git fetch + git merge
работает она так, сначала через git fetch получает новое состояние ветки из origin, а потом передает управление git merge , он в свою очередь если ваша ветка разошлась делает merge, если нет то делает fast forward как следствие могут появиться не нужные комиты вида «Merge branch «test» to «test»»

По этому советую вместо git pull делать всегда git fetch , а потом смотреть git status а там уже либо git rebase origin/test либо git pull

2. так же как вам уже сказали выше у вас есть изменения в локальных файлах, в целом в этом нет ничего плохого, их можно либо спрятать через git stash либо сделать комит

Источник

Git Your local changes to the following files would be overwritten by merge Solution

You cannot pull code from a remote repository if there are any conflicts between uncommitted changes you have made on your local machine and the contents of the remote repository. This protects you from overwriting code you want to keep.

In this guide, we discuss the вЂњYour local changes to the following files would be overwritten by mergeвЂќ error and why the error is raised. WeвЂ™ll also walk through an example so you can learn how to solve this error.

Your local changes to the following files would be overwritten by merge

Your local version of a repository will often be different than that of a remote repository. This is a core feature of Git : you can make changes locally without pushing them to the remote repository until you are ready.

Find Your Bootcamp Match

Career Karma matches you with top tech bootcamps
Access exclusive scholarships and prep courses

Select your interest
First name

Last name

Phone number

By continuing you agree to our Terms of Service and Privacy Policy , and you consent to receive offers and opportunities from Career Karma by telephone, text message, and email.

When you pull code from a remote repository, Git will retrieve the contents of that repository and save them to your local machine. This can only happen if you have committed all of the changes to files that you want to save.

If you try to pull code without first committing changes, you may see the вЂњYour local changes to the following files would be overwritten by mergeвЂќ error. This will only happen if you have modified a file that has also been changed in the remote version of the repository.

An Example Scenario

LetвЂ™s make a revision to a Git repository called ck-git. First, letвЂ™s clone a copy of this repository :

We now have a copy of the repository on our local machine. This repository contains one file: README.md. Its contents are:

We are going to go to GitHub and modify this file on the server. Our file now contains the contents:

Our local version of the repository is now different from the origin master branch on the remote version of the repository.

Our version contains the code that was in the remote repository when we pulled the code. The remote repository contains the change that we have made to README.md.

Now, letвЂ™s say that we change README.md on our local machine:

We have changed our file. Now, letвЂ™s try to pull the changes we made to our remote repository so that we can save them to our local machine:

This command returns an error:

We have shortened the response of this command for brevity. The message we should focus on is вЂњYour local changes to the following files would be overwritten by mergeвЂќ.

«Career Karma entered my life when I needed it most and quickly helped me match with a bootcamp. Two months after graduating, I found my dream job that aligned with my values and goals in life!»

Venus, Software Engineer at Rockbot

Find Your Bootcamp Match

The Solutions

There are now two copies of our file: the one on our local machine and the one in our remote repository. When we pull our code from our remote repository, Git is unsure what version of the file should remain.

To solve this error, we can either stash our code or commit our code.

To commit our code, we can add our README.md file to a commit and create a commit containing that file:

This will add the changes we made to README.md on our local machine to the commit history of our project. Git will now know that we want to keep these changes.

The second solution is to stash our changes. This lets us save our changes for later viewing. We can stash our code using the git stash command :

This command saves our change into a stash (our code is вЂњstashed awayвЂќ for later). Now that weвЂ™ve stashed our code, we can safely pull the code from our remote repository:

The code in a Git stash can be viewed by running the git stash pop command. This will let us see the changes weвЂ™ve made to our file that we did not commit to our repository. This means that if we decide we want to commit the changes to the file later, we can do so.

Conclusion

The вЂњYour local changes to the following files would be overwritten by mergeвЂќ error occurs when you try to pull a remote repository to your local machine whose contents conflict with the contents of your local version of the repository.

To fix this error, either stash your changes away for later or commit your changes. Now you have the knowledge you need to fix this error like an expert!

About us: Career Karma is a platform designed to help job seekers find, research, and connect with job training programs to advance their careers. Learn about the CK publication.

Источник

Git FAQ

Frequently asked questions around Git and Version Control.

How do I force git pull to overwrite local files?

When working on a project with a team, you might stumble upon error messages like these when trying to perform a «git pull» in your repository:

The reason for error messages like these is rather simple: you have local changes that would be overwritten by the incoming new changes that a «git pull» would bring in.

For obvious safety reasons, Git will never simply overwrite your changes. This also means that there is no «force pull» feature in Git — but we can of course perform a couple of steps to emulate such a command.

Step 1: Cleaning Up the Working Copy

First, you’ll need to make sure your working copy doesn’t contain these conflicting changes anymore. There are two ways to achieve this:

a) Saving Local Changes on a Stash

If you want to preserve your local changes, you can safely store them on a Stash. They will be available in case you want them back at a later point.

b) Discarding Local Changes

If you are sure that you don’t need them anymore, you can discard your local changes completely:

If you also have untracked / new files, you will have to use the «git clean» command to get rid of these, too:

Please be careful with these commands: discarding local changes and untracked files cannot be undone!

Step 2: Pull Again

After you have cleaned up any local changes / untracked files that would have been overwritten, the pull will finally work:

Auto-Stashing in Tower

If you’re using the Tower Git client, you’ll notice that it helps you avoid these situations: whenever you have uncommitted local changes present and want to perform an action like Pull, Checkout or Merge, Tower will automatically offer to store these changes safely on a Stash.

This way, you neither have to take any extra steps nor do you have to think about this anymore.

Learn More

Check out the chapter Integrating Remote Changes in our free online book
More frequently asked questions about Git & version control

Get our popular Git Cheat Sheet for free!

You’ll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.

About Us

As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.

Just like with Tower, our mission with this platform is to help people become better professionals.

That’s why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.

Источник

When working on a project with a team, you might stumble upon error messages like these when trying to perform a «git pull» in your repository:

error: Your local changes to the following files would be overwritten by merge: ...

-or-

error: Untracked working tree file 'images/icon.png' would be overwritten by merge

The reason for error messages like these is rather simple: you have local changes that would be overwritten by the incoming new changes that a «git pull» would bring in.

Step 1: Cleaning Up the Working Copy

First, you’ll need to make sure your working copy doesn’t contain these conflicting changes anymore. There are two ways to achieve this:

a) Saving Local Changes on a Stash

If you want to preserve your local changes, you can safely store them on a Stash. They will be available in case you want them back at a later point.

$ git stash --include-untracked

b) Discarding Local Changes

If you are sure that you don’t need them anymore, you can discard your local changes completely:

$ git reset --hard

If you also have untracked / new files, you will have to use the «git clean» command to get rid of these, too:

$ git clean -fd

Please be careful with these commands: discarding local changes and untracked files cannot be undone!

Step 2: Pull Again

After you have cleaned up any local changes / untracked files that would have been overwritten, the pull will finally work:

$ git pull

Auto-Stashing in Tower

This way, you neither have to take any extra steps nor do you have to think about this anymore.

Learn More

Check out the chapter Integrating Remote Changes in our free online book
More frequently asked questions about Git & version control

Источник

MiniTool
MiniTool News Center
Fix Git Error — Your Local Changes Would Be Overwritten by Merge

By Daisy | Follow |
Last Updated August 31, 2022

If you have modified files that also have modifications in the remote repository, you may receive the “your local changes to the following files would be overwritten by merge” error message. This post from MiniTool offers fixes.

What Is a Repository? What Is Push and Pull in Git?

What is a repository? A repository is a store of code that team members are constantly modifying and fetching through the GitHub version control mechanism.

«Pull» means that you pull the latest version of the repository to your local storage/IDE (Integrated Development Environment) such as Pycharm etc. After pulling, you can change the code or add more functionality. When you’re done, you «push» your code to the repository so your changes can be saved and added. Others can also access the code.

How to Fix “Your Local Changes to the Following Files Would Be Overwritten by Merge”

Fix 1: Force a Pull to Overwrite Local Changes

The first method for you is to force a pull to overwrite local changes. This will overwrite any local changes done on your computer and a copy of the version in the repository will appear. You need to run the following commands in IDE.

git reset — hard
git pull

Then, you can check if the “error: your local changes to the following files would be overwritten by merge:” message has gone.

Fix 2: Keep Both Changes

If you want to keep both of these changes (the one done locally and the one in the repository), you can add and commit your changes. You need to execute the following codes in IDE:

git add $the_file_under_error
git commit
git pull

Fix 3: Keep Both Changes but Not Commit

It happens from time to time that the developer is not ready to commit because you are debugging some partially broken code. Here we can safely stash the changes, pull the version from the repository, and unstore your code.

git stash save —keep-index

git stash
git pull
git stash pop

If there are some conflicts after popping into the store, you should resolve them in the usual way. You can also use the following codes:

git stash apply

If merging is not a viable option for you, consider rebasing In the case of rebasing, change the code to

git stash
git pull —rebase origin master
git stash pop

Fix 4: Make Changes to Parts of Your Code

If you want to make changes to a specific part of the code and don’t want to replace everything, you can commit everything you don’t want to override and follow fix 3. You can use the following codes to make changes you want to override from the version that exists in the repository:

git checkout path/to/file/to/revert

git checkout HEAD^ path/to/file/to/revert

Also, you need to make sure that the file is not staged via:

git reset HEAD path/to/file/to/revert
git pull

Also see: Fix Git Error: You Need to Resolve Your Current Index First Now!

Final Words

These are common solutions to fix “your local changes would be overwritten by merge” in Git. If you have any other useful methods to remove this error, leave a comment below to let us know.

About The Author

Daisy

Position: Columnist

She was graduated from the major in English. She has been the MiniTool editor since she was graduated from university. She specializes in writing articles about backing up data & systems, cloning disks, and syncing files, etc. She is also good at writing articles about computer knowledge and computer issues. In daily life, she likes running and going to the amusement park with friends to play some exciting items.

Источник

When you learn to code, sooner or later you’ll also learn about Version Control Systems. And while there are many competing tools in this space, one of them is the de facto standard used by almost everyone in the industry. It’s so popular that there are companies that use its name in their branding. We’re talking about Git, of course.

While Git is a powerful tool, its power is well-hidden. There are some essential concepts that you need to understand to become really proficient with Git. The good news is that once you learn them, you’ll hardly ever run into trouble you can’t escape from.

The Typical Workflow

In a typical Git workflow you’ll use a local repository, a remote repository, and one or more branches. Repositories store all the information about the project, including its entire history and all the branches. A branch is basically a collection of changes leading from an empty project to the current state.

After cloning a repository, you work on your local copy and introduce new changes. Until you push local changes to the remote repository, all your work is available only on your machine.

When you finish a task, it’s time to synchronize with the remote repository. You want to pull the remote changes to keep up with the project’s progress, and you want to push the local changes to share your work with others.

All is well when you and the rest of your team are working on totally separate files. Whatever happens, you won’t be stepping on each other’s feet.

However, there are times when you and your teammates simultaneously introduce changes in the same place. And that’s usually where the problems begin.

Have you ever executed git pull only to see the dreaded error: Your local changes to the following files would be overwritten by merge:? Sooner or later, everyone runs into that problem.

What’s more confusing here is that you don’t want to merge anything, just pull, right? Actually, pull is a bit more complicated than you might have thought.

How Exactly does Git Pull Work?

Pull is not a single operation. It consists of fetching data from the remote server and then merging the changes with the local repository. These two operations can be performed manually if you want:

git fetch
git merge origin/$CURRENT_BRANCH

The origin/$CURRENT_BRANCH part means that:

Git will merge the changes from the remote repository named origin (the one you cloned from)
that have been added to the $CURRENT_BRANCH
that are not already present in your local checked out branch

Since Git only performs merges when there are no uncommitted changes, every time you run git pull with uncommitted changes could get you into trouble. Fortunately, there are ways to get out of trouble in one piece!

Photo by Sneaky Elbow / Unsplash

Different Approaches

When you have uncommitted local changes and still want to pull a new version from the remote server, your use case typically falls into one of the following scenarios. Either:

you don’t care about the local changes and want to overwrite them,
you care about the changes very much and would like to apply them after the remote changes,
you want to download the remote modifications but not apply them yet

Each of the approaches requires a different solution.

You Don’t Care About the Local Changes

In this case, you just want to drop all the uncommitted local changes. Perhaps you modified a file to experiment, but you no longer need the modification. All you care about is being up to date with the upstream.

This means that you add one more step between fetching the remote changes and merging them. This step will reset the branch to its unmodified state, thus allowing git merge to work.

git fetch
git reset --hard HEAD
git merge origin/$CURRENT_BRANCH

If you don’t want to type the branch name every time you run this command, Git has a nice shortcut pointing to the upstream branch: @{u}. An upstream branch is the branch in the remote repository that you push to and fetch from.

This is how the above commands would look like with the shortcut:

git fetch
git reset --hard HEAD
git merge '@{u}'

We are quoting the shortcut in the example to prevent the shell from interpreting it.

You Very Much Care About the Local Changes

When your uncommitted changes are significant to you, there are two options. You can commit them and then perform git pull, or you can stash them.

Stashing means putting the changes away for a moment to bring them back later. To be more precise, git stash creates a commit that is not visible on your current branch, but is still accessible by Git.

To bring back the changes saved in the last stash, you use the git stash pop command. After successfully applying the stashed changes, this command also removes the stash commit as it is no longer needed.

The workflow could then look like this:

git fetch
git stash
git merge '@{u}'
git stash pop

By default, the changes from the stash will become staged. If you want to unstage them, use the command git restore --staged (if using Git newer than 2.25.0).

You Just Want to Download the Remote Changes

The last scenario is a little different from the previous ones. Let’s say that you are in the middle of a very messy refactoring. Neither losing the changes nor stashing them is an option. Yet, you still want to have the remote changes available to run git diff against them.

As you have probably figured out, downloading the remote changes does not require git pull at all! git fetch is just enough.

One thing to note is that by default, git fetch will only bring you changes from the current branch. To get all the changes from all the branches, use git fetch --all. And if you’d like to clean up some of the branches that no longer exist in the remote repository, git fetch --all --prune will do the cleaning up!

Photo by Lenin Estrada / Unsplash

Some Automation

Have you heard of Git Config? It’s a file where Git stores all of the user-configured settings. It resides in your home directory: either as ~/.gitconfig or ~/.config/git/config. You can edit it to add some custom aliases that will be understood as Git commands.

For example, to have a shortcut equivalent to git diff --cached (that shows the difference between the current branch and the staged files), you’d add the following section:

[alias]
  dc = diff --cached

After that, you can run git dc whenever you wish to review the changes. Going this way, we can set up a few aliases related to the previous use cases.

[alias]
  pull_force = !"git fetch --all; git reset --hard HEAD; git merge @{u}"
  pf = pull_force
  pull_stash = !"git fetch --all; git stash; git merge @{u}; git stash pop"

This way, running git pull_force will overwrite the local changes, while git pull_stash will preserve them.

The Other Git Pull Force

Curious minds may have already discovered that there is such a thing as git pull --force. However, this is a very different beast to what’s presented in this article.

It may sound like something that would help us overwrite local changes. Instead, it lets us fetch the changes from one remote branch to a different local branch. git pull --force only modifies the behavior of the fetching part. It is therefore equivalent to git fetch --force.

Like git push, git fetch allows us to specify which local and remote branch do we want to operate on. git fetch origin/feature-1:my-feature will mean that the changes in the feature-1 branch from the remote repository will end up visible on the local branch my-feature. When such an operation modifies the existing history, it is not permitted by Git without an explicit --force parameter.

Just like git push --force allows overwriting remote branches, git fetch --force (or git pull --force) allows overwriting local branches. It is always used with source and destination branches mentioned as parameters. An alternative approach to overwriting local changes using git --pull force could be git pull --force "@{u}:HEAD".

Conclusion

The world of Git is vast. This article covered only one of the facets of repository maintenance: incorporating remote changes into a local repository. Even this everyday scenario required us to look slightly more in-depth into this version control tool’s internal mechanisms.

Learning actual use cases helps you better understand how Git works under the hood. This, in turn, will make you feel empowered whenever you get yourself into trouble. We all do that from time to time.

Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Источник