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

Asked 30/12, 2020 at 0:19 Answered 21/7 at 19:59

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?

Suppressive answered 30/12, 2020 at 0:19 Comment(0)

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

Racecourse answered 30/12, 2020 at 2:0 Comment(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)

Apophyllite answered 30/12, 2020 at 0:36 Comment(0)

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

Zinovievsk answered 1/9, 2022 at 10:2 Comment(0)

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.

Apophyllite answered 21/7 at 19:59 Comment(0)

Recommended topics

Hot tags