"Stop.
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
STEP 1
If you have collaborator permissions for the shared repo, do this:
In your terminal, type:
git status
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.
STEP 2
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
STEP 3
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.
STEP 4
I code away in my code editor, tappity-tap.
STEP 5
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 .
STEP 6
Then I commit the changes:
git commit -m 'my awesome improvements to our app'
STEP 7
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)
git push
STEP 8
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
STEP 9
If you ran git status
you would know now to:
git push
STEP 10: Collaborate
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.
So I:
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.
STEP 11
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
STEP 12
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.
STEP 13
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.
STEP 14
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.
STEP 15
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)
STEP 16
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
STEP 17
I want to make a new branch and start this cycle all over again from STEP 1.
Rinse. Repeat.
Top comments (27)
Nice post Funda.
For STEP 4, I'd also suggest
git add -p
as a means of deciding which files to include. It lets you step through all your changes and give ay
orn
to decide what to stage.I love that. I am trying to be absolutely minimal (MVP) here, since this was written for the classroom & there is always a lot of confusion when students first encounter this. Perhaps I will add links to handle more shortcuts, best practices, and features.
👌
This is a nice article, however steps 9 and 10 should be swapped.
First you pull the updated master and then you remove the feature branch. Otherwise you will need to force branch delete (git branch -D) because your local repo doesn't know yet that the branch is already merged. And forcing is not nice ;).
Cheers!
yes this is right --- I will edit! And you are correct that forcing anything isn't nice at all.
Thank you for the improvement!
Should there be a
git merge master
between steps 6 and 7? I try to resolve conflicts, if any, before I submit the PR.Jeffrey,
Your question is valid 100%. after git checkout mybranchname we should perform a git merge master. It is at this stage that conflicts may appear and you have a chance to fix them. This way you make sure your branch won't conflict with the remote master branch.
Even more, when several developers are working release updates constantly to the master branch, we advise them to perform this sync process often to see how your changes operates in the whole application.
the merge happens on the website not from the terminal. This is for students to be able to visualize it in the GUI.
So are you saying that git pull origin master is not required? Why would I pull master locally then just push my branch up?
git pull origin master is being executed again at step 5. when you push to your branch it creates the pull request on the github website.
Updated with changes!
Hey Funda nice effort you've put in the article. I've also written an article on Manage Branches and Resolve Conflicts. Your Feedback would be welcome :)
cloudways.com/blog/manage-branches...
Hi Funda,
Shouldn't one pull from the master after committing changes to your branch so that you are up to date and can resolve and merge conflicts before doing the PR?
you mean switch to master, 'git checkout master', then switch back to branch and 'git push origin branch'? Yes...this is what I do, but I found with students too much switching caused confusion. It's either extra switching or extra merge conflicts.
Maybe I'm confused, but I thought that if others have been working on their own branch and in the process of working on mine, a few PRs have been merged...so before I push to my remote and initiate a PR, I should git pull from the current master to my branch?
Kind of like this:
Then open a PR.
You can so you will eventually get conflicts on your feature branch and solve them before pushing to remote.
that's in the steps now, edited ;-)
I see that in
Step 5
you switch back to master to pull to your local copy of master, but how does that update your local branch without pulling master to your local branch?I guess I still don't really understand why you would switch back to master and then back to branch. Thanks!
Valid question. Just doing
git pull origin master
in Step 5 will NOT update your local branch. This tutorial is missing a step between 6 and 7. Essentially after yougit pull origin master
in Step 5, andgit checkout mybranchname
in step 6, you will rungit merge master
to combine the master branch changes into your feature branch, namedmybranchname
. Hope that helps!You skipped a step between 4 and 5 - you forgot to create the pull request.
It’s implied in the ‘keep clicking green buttons’ part after you go to the Github site. I have edited this now to assume reader has collaborator permissions. You are right that if this were an open source project, the user would have to create a pull request. But these steps are for students who are just learning to become team collaborators, and for them, the pull request is created when you
push origin mybranchname
in terminal. Thank you!I really like using the following to flip back and forth between the two most recent branches. Saves time and having to remember some complicated branch name!
Thanks, Funda. This is a nice post. Some developer who started to git as a beginner should read this post. I'll share.
I love this post with that style,especially the beginning of group pictures! HaHa