1

If using modern IDE like IntelliJ or Eclipse and working on a local feature branch, is it ok to directly pull changes from origin/develop branch to sync latest changes instead of checkout and pull latest develop branch to do a merge locally? I think common IDE can do merge smartly and even if there is conflict, it has to resolve it manually anyway.

I can see the checkout develop-- pull -- merge from feature branch adopt the git workflow from command line mode and doing the merge locally, however if developer only care about local feature branch, is it necessary to have extra route to get fresh version of the develop branch locally?

Dreamer
  • 7,333
  • 24
  • 99
  • 179
  • 1
    You could just rebase onto `origin/develop` without checking out locally too. Or if you dislike rebasing for some reason, you could also merge `origin/develop` without checking out locally. (Just fetch first.) The pull will fetch and merge/rebase for you in a single command, and it's nearly identical. (I think the exceptions occur when someone force pushed develop in which case fetch/rebase is better than pull with rebase.) – TTT Aug 19 '21 at 14:02
  • @TTT thanks much for the comment, "Just fetch first" I think pull is fetch+merge by default so does fetch first necessary? – Dreamer Aug 19 '21 at 15:32
  • 1
    I meant that if instead of using `pull`, if you use the `merge` or `rebase` commands, make sure to `fetch` first. If you use `pull` you don't need to `fetch` first. After using Git for a while I stopped using `pull` anymore, for various reasons, and I now almost always fetch and merge or fetch and rebase instead. (One reason is I almost exclusively rebase, and pulling with -r isn't *exactly* the same as fetch and rebase, as mentioned in a comment to Enrico's answer.) – TTT Aug 19 '21 at 15:42

1 Answers1

0

There's no "risk" involved in pulling changes from origin/develop directly into your local feature branch without first updating your local develop branch. However, there are a couple things you should keep in mind:

  1. Do a pull rebase instead of a regular merge
  2. When you compare your local feature branch with your local develop branch, the former is going to contain commits that you didn't make, but that instead came from origin/develop

Here's an example that illustrates this scenario:

o---o develop
     \
      A---B---C feature

o---o---D---E origin/develop

Once you pull in the commits from origin/develop directly into feature, either from the IDE (make sure you enable the rebase option) or with git pull -r origin develop, the branch is going to look like this:

o---o develop
     \
      D---E---A'---B'---C' feature

o---o---D---E origin/develop

Now, if you compare feature with the local develop, it's going to look like commits D and E were created in the feature branch, while, in reality, they came from origin/develop.

Of course, once you sync your local develop with origin/develop, everything is going to look like you expect:

o---o---D---E develop
     \
      A'---B'---C' feature

o---o---D---E origin/develop

I wrote a blog post that explains why the default git pull with a shared branch leads to a more complicated history.

Enrico Campidoglio
  • 56,676
  • 12
  • 126
  • 154
  • Note there is some (arguably very) small risk to pulling with rebase compared to fetch and rebase in separate commands. See [this question](https://stackoverflow.com/q/66535801/184546) and my answer, which is kind of a summary of the duplicate link to torek's (better) answer. – TTT Aug 19 '21 at 15:29
  • @Enrico Campidoglio hats off for the nice explanation with example in details. May I ask if not choosing `-rebase` but do the pull with default `-merge`, is it going to be problematic? – Dreamer Aug 19 '21 at 15:30
  • 1
    @Dreamer I think the answer depends on your own workflow. When you start adding merge commits to your own feature branches, it makes it more complicated if you want to modify any commits before that merge. So, if you like using `rebase -i` then you should rarely use merge. Or, if you think you *might* want to fixup commits, then also rarely use merge. I've never met a programmer that doesn't make mistakes and never changed their mind. But I've met plenty of people that never look at their commit history and simply don't care if there are many unnecessary commits and merge commits in the repo. – TTT Aug 19 '21 at 15:46
  • @TTT The risk you're referring to is to reintroduce a commit that was deliberately removed in the upstream `origin/dev` branch by means of force pushing. Yes, that risk does exist, but it assumes that the team is OK with force pushing a shared long-running branch without warning. That's a dangerous policy to have in the first place. – Enrico Campidoglio Aug 20 '21 at 07:46
  • @Dreamer I wrote a [blog post](https://megakemp.com/2019/03/20/the-case-for-pull-rebase/) explaining why the default `git pull` with a shared branch is a bad idea. I hope you find it useful. – Enrico Campidoglio Aug 20 '21 at 07:49
  • @EnricoCampidoglio that's not the risk I'm referring to. I'm talking about the edge case where `git pull -r` doesn't work as intended because of a different fork point, which is caused by a forced push. It's a rare case where `git pull -r` acts differently than `git fetch && git rebase @{u}`. (But yeah, if you don't force push shared branches you won't encounter it...) – TTT Aug 21 '21 at 03:43