Introducing the Break Git Down Series!
Break Git Down is a super beginner-friendly series to help newer developers learn a few of the most important Git tasks that you will certainly use. Git is an essential part of every day life as a developer and my goal is to help make the transition to using Git (and ultimately the command line), a smooth and hopefully easy learning curve.
Why Learn it?
Git was one of the things I was scared of when I was learning how to code- mostly due to my irrational fear of the command line. Instead, I used GitHub Desktop which allowed me to lazily drag and drop files. However when I was hired in my first tech role, I soon realized how essential it was to be acquainted with using Git in the terminal. It's an essential part of our everyday lives as developer to use it!
For sake of brevity, we're going to assume you are working in an existing repository (aka project that already has a Master branch)
Why Would I Create a Branch Separate From the Master Branch?
To put it in the simplest way, the Master branch contains all of the official code for a project (aka repository). In a typical workplace, we would NEVER directly push code directly to master as a way to reduce the chance of shipping bugs and unnecessary code to production (aka live site). Instead, the safest thing to do is to create additional branches that are separate from the Master branch. Think of them as different versions of your project.
Now Let's Get to Pushing!
Let's see what branch we are currently in! When we run git branch, it will display all of the branches that are associated with the repository.
The branch that is highlighted indicates where in the repository we are currently located.
Next, we will change our location to the master branch so we can be able to start off fresh when we create our new branch! (If you're already in the Master branch, perfect!)
git branch
git checkout master
Let's create a new branch. In this tutorial, we'll call it "newer-branch"
Git checkout -b "newer-branch"
Now we've created a new branch so that means whatever change we make (ie creating a file or editing an existing one), will only affect this branch! This is great because we are keeping our code organized and we reduce the risk of messing up the whole project lol.
So make any changes that you want to the new file. In this instance, I updated the README file.
Next we will add the file to our commit. Choose one of two commands.
The first command will add all files to the commit. You would usually only do this if you have made changes to every file or if there is only one file in the repo.
git add .
Option #2 (The one we will do in this tutorial) will only add the file that you specify that you want to commit! You will have to specify the relative path of the file you want to commit. In this case, it will be the README file.
git add README.md
Next, let's add a detailed description of what we've changed in our commit. -m simply stands for message.
git commit -m "add a detailed description"
The git push command allows you to send the commits from your local branch in your local Git repository to the remote repository and it will provide us the exact command we need to push our beautifully new branch to our Git repository! (my favourite command). Later on, we'll be able to merge our "newer-branch" commit to our master branch.
git push
git push --set-upstream origin newer-branch
Now, let's check our GitHub!
A helpful reminder I'll always advise throughout the series is to practice, practice, practice! You'll learn through repetition. I hope you've enjoyed the first part of the Break Git Down Series. Stay tuned for more!
Top comments (23)
I believe that you have covered all the touch points required in order to fulfill the task.
However, like most programming books, it may be a good idea to filter your audience beyond your experience. For example, if I don't have git loaded or have seen git GUI or know how to get to my workstation command prompt, then where do I begin? Is this article for me or someone more advanced? In other words, are there any pre-conditions that must be met before continuing to reading the blog.
As in SOPs, often there are pre-reqs or conditions that must exist prior to completing the next step in sequence or task. What do those conditions look like when they are completed properly and incorrect, prior to moving forward.(visuals)
Highlight, as you did, the risk prior to and consequences of completing a task incorrectly. What to do if it happens. What to do in order to get back on course.
What happens if you get GOT trying to Git?
I like it because your pace and language is relaxed and not intimidating. That is BIG, considering I'm not a big Git user.
Today a blog. Tomorrow a book or whitepaper.
Thanks for the detailed feedback. In one of my next posts I'm going a bit backwards and go over how to configure Git as well as how to create a repository.
Patiently waiting for this. Thanks for the good work! :d
Of course 😊🤓
Second everything here.
...and taking notes from both author and commenter for MY posts...
scribbles notes emphatically
😂
Thanks for the article, always appreciate a clearly written piece that doesn't get bogged down.
I would have liked more info on that git push command though.. it doesn't really explain what you're doing.
Looking forward to reading some more though!
Try this: git checkout origin/master -b newer-branch
This will do the following:
Use "git branch -vv" to see the difference between "git checkout -b newer-branch" and "git checkout origin/master -b newer-branch-2"
I'm stumbling over this sentence:
I'm confused here. It doesn't push to master, does it? I thought it creates a new branch on the server with the same name as my "newer-branch"?
Yep you're correct. I didn't articulate it that well.
Thanks for clarifying!
This is a good related article about setting up alias
The Git Aliases That Get Me To Friday
Matt Miller
And here is more information about setting up alias: techradar.com/how-to/computing/app...
This is useful for common git commands you'll be repeating dozens of times every day!
Very simple yet thorough breakdown, excellent article!
Thank you so much Jyrone 😆🤓
Nice write up but you kind of miss the details of this line: git push --set-upstream origin newer-branch
Thanks for the feedback 👍
Great article! Looking forward to seeing more, I especially like the gifs. Might be worth noting that 'git add .' is specifically referencing files inside of this directory, so if like me you sometimes 'cd' to other places within your git repo, 'git add .' wont add all the files that changed, just the ones that changed within your current directory. You can do things like 'git add ../../' to add the files from directories higher up the tree.
You should try using tortoise git, its a lot better than the github desktop version.
I like the command line now but I'll try it out solely to give my opinion on it when I put out the article for beginners on which way they can learn git :)
Yeah I feel like the command its the correct way, however I always suggest learning first the concept and use an UI tool and then use the console. Tortoise git is very helpful in that sense since it expose the command that he used
Really helpful clear guide, thanks for the help! :)