3

For instance, let's suppose I have a branch called develop, and all my features will be a branch created from develop that later I will need to do a merge request (in GitLab, what in GitHub would be a pull request).

If I need to update my new branch before push it into origin and do a merge/pull request, does "git pull origin develop" would update my new branch too?
If not, how can I do this?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Vitorfigm
  • 31
  • 1
  • 3

3 Answers3

3

There are a few methodologies, and it depends on the branching strategy that you are using. On a project-by-project basis, I would pick one strategy and stick with it, but the one that works best depends on what you are looking for.

Merge: (execute from the branch):

  • git pull (or git fetch)
  • git merge origin/develop
  • git push

This preserves history and is non destructive. It creates a single new commit on the branch representing the change(s) from develop being brought into the branch.

Rebase: (execute from the branch):

  • git pull --rebase (or git fetch)
  • git rebase origin/develop
  • git push --force (or git push -f)

This REWRITES history and is destructive. The original commits on the branch are discarded and recreated (they will look similar (same comment, file and authorship), but will have different commit-ids and commit-time. It makes history more 'linear'.

Rebase with squash: (execute from the branch):

  • git pull (or git fetch)
  • git rebase origin/develop
  • git rebase -i HEAD~2 (assuming branch is 2 commits ahead of develop)
  • git push --force (or git push -f)

Similar to rebase (above) - rewrites and destructive - but collapses the branch down to a single commit. History is not only linear, it is also concise - entire branches are collapsed to a single commit.

My usual advice is to avoid using rebase with inexperienced teams. It's easy to get into trouble with rebase and there are all sorts of things to be wary of. Nevertheless, rebase makes for pretty history (if that's important) - but forensics is made harder (if that's important). The "--force" is git's way of telling you that you are taking the safeties off and to be careful what you are doing.

Check out the man page on git-pull. There are commands to collapse pull/merge or pull/rebase to reduce the steps by one. There are also git-config commands to specify that a 'pull' is always a 'pull-and-merge' or 'pull-and-rebase'.

Jeff Bennett
  • 996
  • 7
  • 18
0

The proper command would by:

git fetch
git switch myNewBranch
git rebase origin/develop
git push --force

That way, you are replaying (rebase) your new branch on top of an up-to-date origin/develop

The existing pull request/merge request would be updated automatically, and its resolution would be a trivial merge (since myNewBranch commits are all new commits on top of the target branch develop)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Just git merge origin/your-source-branch-to-merge-from. The magic is within the origin/ prefix.

D. Walz
  • 75
  • 7