If you want to create a feature branch from master and not wreck the timeline for everyone else on the team then this tiny git tutorial will help. It covers switching to master, updating it from the remote, creating a new git branch, and pushing that branch so your CI and reviewers can do their thing. Yes this is the part of version control that keeps projects moving and arguments to a minimum.

Switch to master

Always start on the main line of development. Run git checkout master to move your working tree to master. If your repository uses main replace master with main in the commands below. Do not start a branch from whatever random branch you have lying around.

git checkout master

Update master from the remote

Make sure master matches the remote so you do not branch from stale code and later enjoy merge headaches. The quick option is git pull origin master. If you prefer a cleaner history then run git fetch origin and then merge the remote tip into your local master.

git pull origin master

or for a two step flow

git fetch origin

git merge origin/master

Create a new branch from master

Name things so your future self and your reviewer do not weep. Use a concise feature name that includes scope like feature/add-login or fix/typo. Create and switch in one command with git checkout -b feature-name. Newer Git versions also support git switch -c feature-name if you prefer that style.

git checkout -b feature-name

or

git switch -c feature-name

Push the new branch to origin

Share the branch with your team and trigger CI by pushing it. Use git push -u origin feature-name. The -u flag makes your next git push and git pull simpler because it sets the upstream tracking branch for you.

git push -u origin feature-name

Start work and open a pull request

Make small commits with clear messages and push often. When you are ready open a pull request on your hosting platform and request reviews from the right humans. If your branch lags behind master you can rebase or merge to stay compatible. Keep the history readable and resolve conflicts locally if needed.

Rebase or merge which to choose

• Rebase keeps a linear history and is neat for short lived feature branches
• Merge preserves the exact topology and is safer on long running branches with many collaborators
• If your project uses a strict merge policy follow that policy to avoid CI surprises

Quick checklist before opening a pull request

• Switch to master and update from remote with git pull origin master
• Create a branch with git checkout -b feature-name
• Commit often and push with git push -u origin feature-name
• Rebase or merge master if the branch gets out of date
• Open a pull request and request a review

There you go. Follow these steps and you will avoid messy merges and awkward team standups. If something goes wrong remember that git reflog is a time machine and your mistakes are not permanent unless you want them to be.