With Git, these two commands might be used hundreds of times a day.

It is believed that most people will pull directly and fetch occasionally. But what’s the difference between these two?

I’m not going to talk too much about the theory, because it’s very boring, and I know it might be confusing. Let’s talk about usage scenarios.

Should I Fetch or Pull

Should Pull is for the most part the case.

Before you Pull on your branch, Git will fetch only your branch. If you need to look at other branches, you’d better do the fetch command.

As an example of a usage scenario, the following flow is probably the one most people use.

You are now working on your branch called CI, and the main branch of your project is master.

In many cases you may be pulling your branch CI directly, at which point the fetch is performed. If you want to view your local master branch, then you need to pull again after switching branches.

If you fetch the entire project, you don’t need to pull anymore.

Because many companies’ project specifications do not allow you to submit changes to the master directly, you must use PR to merge the changes to the master. If your company does not have this specification, then you should remember to merge the changes from the remote master to your local fetch.

Fetch synchronizes the local repository with the remote repository, pulling changes from the remote repository to your local repository without doing anything.

So, the general practice is to pull as long as you don’t switch branches while you’re working hard in your branch CI.

Someone has modified your branch

Usually we are not working alone, and you have a very difficult problem. Fortunately, there is a god in the project team to fix it for you.

At this point he will Push his changes into your branch CI.

You need to see what the god has changed. You can just pull directly and see what he has changed in the commit log.

Because pull involves merging, conflicts can arise.

If there are conflicts, you need to manually merge the conflicts and then commit.

This usage scenario is one that many people will encounter.

The pull from the master

Usually master is the primary branch, and some projects have dev, or a different branch for CI.

Sometimes these branch changes need to be incorporated into the branch you are developing.

At this point you can use the Pull from remote branch to your local location. Fetch is also performed before this command is executed.

IJ provides two options, you can choose Rebase or Merge.

This feature allows you to keep your branches consistent with the branches on the Master, avoiding unexpected complications and conflicts when merging.

conclusion

A Fetch is performed before Pull, but this Fetch may Fetch only your current branch.

If you want your local repository to be consistent with the remote, you can perform a separate Fetch to avoid losing data during a local merge.

Before doing any merging of projects locally, always Fetch your entire project first.

In addition, after arriving at the office in the morning, open IJ and prepare coffee or tea. If nothing else, pull your branch first, fetch the whole project, and then start a pleasant day.

www.ossez.com/t/git-fetch…