CODEWITHSUNDEEP
gitgithubgitlab
Vitorfigm
Vitorfigm

Reputation: 41

How to update(pull) a branch before a pull/merge request?

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?

Upvotes: 4

Views: 11817

Answers (4)

VonC
VonC

Reputation: 1323145

The 2024 command would be suing gh v2.53.0 and PR 8953:

git switch develop
git pull
gh pr update-branch 23 --rebase

That is:

Update a pull request branch with latest changes of the base branch.

Without an argument, the pull request that belongs to the current branch is selected.

The default behavior is to update with a merge commit (i.e., merging the base branch into the the PR's branch).
To reconcile the changes with rebasing on top of the base branch, the --rebase option should be provided.

Upvotes: 0

D. Walz
D. Walz

Reputation: 87

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

Upvotes: 0

Jeff Bennett
Jeff Bennett

Reputation: 1056

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'.

Upvotes: 4

VonC
VonC

Reputation: 1323145

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)

Upvotes: 1

Related Questions