Bring your feature branch up to date with master. Deploying from Git branches adds flexibility. Bring your branch up to date with master and deploy it to make sure everything works. If everything looks good the branch can be merged. Otherwise, you can deploy your master branch to return production to its stable state.

Update-branch.md

Updating a feature branch

First we'll update your local master branch. Go to your local project and check out the branch you want to merge into (your local master branch)

$ git checkout master

Fetch the remote, bringing the branches and their commits from the remote repository. You can use the -p, --prune option to delete any remote-tracking references that no longer exist in the remote. Commits to master will be stored in a local branch, remotes/origin/master

$ git fetch -p origin

Merge the changes from origin/master into your local master branch. This brings your master branch in sync with the remote repository, without losing your local changes. If your local branch didn't have any unique commits, Git will instead perform a "fast-forward".

$ git merge origin/master

Check out the branch you want to merge into

$ git checkout <feature-branch>

Merge your (now updated) master branch into your feature branch to update it with the latest changes from your team.

$ git merge master

Depending on your git configuration this may open vim. Enter a commit message, save, and quit vim:

1. Press a to enter insert mode and append text following the current cursor position.
2. Press the esc key to enter command mode.
3. Type :wq to write the file to disk and quit.

This only updates your local feature branch. To update it on GitHub, push your changes.

$ git push origin <feature-branch>

Thanks!

Thank you for this.

is there way to update automatically using yml code

Thanks a lot. Great explanation 👍

Thanks for this explanation

Thanks a lot ...really appreciated your efforts

Is this the same as rebasing?

@nrowley71115

Rebase is generally not recommended if the branch is already on the remote.

Rebasing rewrites the git history, which means you'll need to use the force option when pushing (since the branch is already on the remote).
Additionally, if there are multiple ppl are working on the same branch, this is error-prone and can lead to conflicts when others pull the branch.
Moreover, in a project with a CI/CD process, rebasing can lead to a cascade of issues.

Saved my life thanks

It's not always convenient to switch back to main (or master) as occasionally a feature branch may have changes which will necessitate stashing before the switch. (turning the OP into roughly git stash && git checkout master && git pull && git checkout - && git stash pop && git merge master (yikes)

I tend to prefer the simpler equivalent which avoids all that:

git fetch origin master
git merge origin/master

Disclaimer: if you have changes which would have prevented a switch to main in the first place you'll still have to deal with them of course - just won't have to do quite so many steps beforehand