5

My normal process for merging in develop to my feature\my-feature branch is:

name@home ~/myRepo (feature/my-feature)
$ git checkout develop
$ git pull
$ git checkout feature/my-feature
$ git merge develop
$ git mergetool

Can this be replaced with:

name@home ~/myRepo (feature/my-feature)
$ git fetch
$ git merge origin/develop
$ git mergetool

Does fetch retrieve enough information about the changes from the remote origin/develop to allow me to merge from origin/develop rather than develop?

Is it bad practice to have feature/my-feature ahead of develop with changes from the remote origin/develop?

StuperUser
  • 10,555
  • 13
  • 78
  • 137

2 Answers2

4

You can directly pull your remote branch develop, but you may need to mention the remote repository (in your case, origin):

git checkout feature
git pull origin develop

This will result in a merge commit, where the message mentions origin/develop.

Without mentioning the remote repo, I'm afraid that the merge part of the pull would merge your local branch develop, not the fetched one. But do try it!

Gauthier
  • 40,309
  • 11
  • 63
  • 97
1

As stated in this question, git pull is just a git fetch followed by git merge.

It's easier for me to think in such terms.

I personally prefer fetching remote branches rather than pulling them, because automatic merge, forced by git pull is not always needed.

Here's how my typical workflow looks like: I always start new features from origin/develop branch

git checkout develop
git fetch origin
git reset --hard origin/develop
git checkout -b new_feature_branch

This ensures I am on a latest origin develop branch.

Why it's better than pull? Because it prevents merge on fetching and helps maintain clean git history.

borisano
  • 1,270
  • 1
  • 16
  • 28
  • How do you merge the latest to your feature branches to prevent conflicts when your changes are pulled into the remote `develop`? That seems like more commands, not fewer. – StuperUser May 21 '15 at 10:14
  • 1
    I'll add my typical workflow in my answer in a minute – borisano May 21 '15 at 10:21
  • In your typical workflow, how do you ensure that `new_feature_branch` is up to date with `develop` before you merge it back in? You should regularly be merging `develop` down into `new_feature_branch` so you merge little and often. – StuperUser May 21 '15 at 12:55
  • I usually only merge before pull request. Why am I merging little and often? – borisano May 21 '15 at 19:50
  • 1
    It depends on the team size, the amount of churn/commits on upstream branches, collisions in files. If you you have a complex merge, the smaller the merge and the sooner to when the other contributor commited, the fresher it will be in minds and easier to merge. E.g. Merging in something complex on a friday afternoon after a lunchtime pint that was worked on 9 days ago, with the contributor on annual leave that could have been merged the week before is suboptimal. – StuperUser May 21 '15 at 19:57
  • But if you are working in a big team with a lot of changes, you will have to merge often anyways. I guess we were talking about initial branch creation. – borisano May 21 '15 at 23:07