Collaborate and Listen." ~ V. Ice
It is highly recommended that you install some kind of decorator for your shell (bash or zsh.) It will help you always know what branch you're in, and it's easier on the eyes. Many use iTerm. I install oh-my-zsh with curl: Visit zsh
If you have collaborator permissions for the shared repo, do this:
In your terminal, type:
As often as you want to. It will give you clues about your next steps in any type of git workflow.
git status, early and often.
I make sure I am in the master branch of my team's shared repository & that I have the LATEST VERSION:
git checkout master
git pull origin master
I make my very own branch. You can make one from the Github site (or Bitbucket or Azure DevOps Repos) but I prefer to do it in Terminal/bash. I name it a name with no spaces, like: "mybranchname". It's best to name it after a feature or fix you're working on.
git checkout -b myNEWbranchname
Now I am in my branch, not the master, so it is safe to make changes.
I code away in my code editor, tappity-tap.
I add my changes:
git add path/to/file-name-here *
*hint: find the paths to names of changed files by running git status
or as a shortcut, to add all files:
git add .
Then I commit the changes:
git commit -m 'my awesome improvements to our app'
If I only want to push changes to the local copy of my branch (see step 8 below, for how you connect it the first time)
First time pushing to the branch? I want the changes to be saved locally on my machine but I also want the remote reference to my branch to reflect them too, so commits are being tracked every time.
This is a common error - branches can get out of sync. Remember git versioning is in your machine but what matters most is the shared repo that lives on another server. The remote branch and the local branch need to reflect each other at all times.
git branch --set-upstream-to=origin/mybranchname mybranchname
If you ran
git status you would know now to:
But hold up. I think someone was working on a feature just now. I don't think I had the latest master code after all. I want to resolve conflicts with the master branch ahead of time, before I make a Pull Request.
git pull origin master - yes from right inside my branch!
This will both fetch my parent branch (in this case master, but it could be some other parent development branch, too) and merge it with my current branch! Remember to fix any merge conflicts now.
If you ran
git status again, you would know to:
git push to push the merged changes to your local branch.
If I get a prompt that I need a commit message to explain the merge, I can exit the editor with
Shift Z Z
I go to my remote repository github.com (ot Bitbucket or Azure DevOps Repos)
Once there, I see "Pull Requests", so I click to go to that page.
I click on my pull request to open it up, and then I click the confirmation (or Approval) button, and click again, until I have satisfied all of the options to confirm the merge*. If there are conflicts, I resolve them before confirming everything and/or completing the merge.
*if you are deploying pipelines with automations connected to your PR (pull request) there may be more steps. That is outside the scope of this document.
You will be asked to delete the branch. This is a best practice, though many people avoid it. Use your discretion. If you keep your branch make sure you are always up-to-date with master before beginning any new work. It's a best-practice to use new, descriptively named branches for bugfixes and features, then delete them after merging.
In my terminal (or git bash,) I bring the remote master code (and all references to commit histories and other branches) into my local branch & push again. My local branch should always be in sync with what's happening in the remote repo. From inside my branch:
git pull origin master
git push (to my branch)
If I had deleted my branch on the site after the PR, in my terminal, I delete the local version of the branch.
git branch -d mybranchname
I want to make a new branch and start this cycle all over again from STEP 1.