Home > other >  What is the use of option: Automatically sync with "origin/Master" in Netbeans?
What is the use of option: Automatically sync with "origin/Master" in Netbeans?

Time:12-29

In Netbeans, I use the Push and Pull from upstream to sync the data between both branches usually. I just found out that there is an option to Automatically sync the two branches:

enter image description here

My questions are:

  1. Does it work the same as the pull and push from upstream?
  2. If yes, does it merge from the origin to the local or the opposite?
  3. On what trigger would it sync?

CodePudding user response:

1- yes.

2- both. The real question is, if your branch and origin's branch diverge, how far does it go? Does it merge? Rebase? What happens if a merge conflict occurs?

3- For you, anytime you commit code on your branch. For changes on origin, there isn't a 'subscribe/publish' style mechanic in git for git repos to let other repos know things have changed (and this would be difficult in practice; most home internets are behind NATs, for example). So, presumably, netbeans will just check a lot. Every 5 minutes, something like that. The git protocol can very efficiently tell you: No, origin/foobar is still at 219a38f23cc12398, or whatever the hashid might be.

The point is to avoid having to manually push and pull.

In general, there are 2 broad-strokes approaches to treating origin (the git repo you sync with).

But first, you have to treat repos in general as follows: You have a repo, the 8 other people working in this team have a repo, it's open source so the 5000 folks who cloned this thing have their repo, and they are all subtly different, or at least, they can be, and that's just how it is. You can't set up git so that everybody has identical repos at all times, that's just not how it works.

Given the above, there are at least 3 'layers' of where code is at: At first, it's just a modification in your editor that you saved. The second layer is that you committed this to your branch (be it main or anything else). The third is that you pushed that commit out to what the team has decided is the central repo.

With that in mind, the 2 ways to treat origin:

  • It's just another repo, just like yours, just like the rest of the team. It can and usually does have a different state. That 3rd layer (push to origin) is a desired separate step. For example, you may want to develop on your local main branch, and even rebase it a bit (which is the act of reviewing your own commits and perhaps re-ordering them, splitting some up, combining others, and rewriting commit messages; the aim is to have a series of commits that stand on their own and which are easy to review. Not just a dump of 'this is all the random stuff I did friday evening' - that's very had to review).

  • It's not really another repo and that third step of pushing is just a drag and nothing more. You would never rebase and review main - instead you develop on a personal/issue branch, review on that, and once you merge with main (locally on your machine) the intent is that that's final. In which case, 'send my commits over to the git repo server and update origin/main' is an important formality.

In that latter model, auto-sync can make sense. It also makes sense if 'the server git repo' serves as your backup solution.

There are a million ways to use git and there is no universally accepted strategy. There are a few standards (these are often called 'git flows'), and you may want to read up on some. Whether it even makes sense to automatically sync depends on the flow you chose.

NB: Some git flows strongly recommend never 'pulling'; a git pull is simply a script that first does a git fetch and then a git merge origin/main: git fetch updates your local copy of the origin/main pointer (branches in git are really just pointers to a given commit ID. origin/main is not: Live-check what origin's main is pointing at; it's a local copy. Almost no git commands interact with the server; pretty much only only git fetch, git push do). Some flows discourage the combination of fetch merge in a single step and instead suggest you fetch, review the changes without necessarily immediately modifying your own local main branch, and only after review, merging your main with origin/main. This flow very much would discourage checking this 'auto-update' checkbox.

  • Related