Challenge to Write Git Tutorial
Tags: git, tutorial, challenge
Published: 2021-06-30 17:50:48

A few years ago for an interview, I was asked to write a git tutorial for beginners. Even thought there was many existing tutorials out there, I thought it was a good challenge to make sure I truly understood git and the uses for it. (Note: I'm an avid GitLab user and I may have referenced that a few times in my completed challenge below.) 

I recommend anybody who has been using git for a long time to try writing your own tutorial and see if you know the basics really well.

Maybe a well written tutorial can teach those who can't code to use git. I firmly believe git can exist in a world beyond developers in other documentation like resume tracking, business documents for small businesses, school work and notes from non programming classes, and others I can't think of at this time. All we need to do is teach the masses of this fantastic tool.

Here is the tutorial I wrote a few years ago:

> ## Git Tutorial for Beginners
>
>For this well known site, I may be a newcomer for posting a tutorial on it. I would like to share I have been using git since 2016 and fell in love with using the tool on the first day I started to learn about it. I am always looking to learn more about git and increase my knowledge and love for the tool. I would like to tell you that we were all beginners and started learning the basics with using git. I will cover those basics, as it's always good practice for even the most experienced people to remember them. 
>
>So you have a project cloned, or a project from something you started with trying to learn to use git with. Well, we are here to learn how take advantage of the `git branch <new-branch>` command or, as my preference is, `git checkout -b <new-branch>`. 
>
>Why would you want to to create a new branch you ask? Well, it's for many reasons: 
>
>* One could be that you don't want to cause any errors on the working production branch, known as master. 
>* Another is looking to just experiment with how things are going in a development environment. 
>* A non-coding example that I could share is that I use git to track my resume versions, and I use branches to play with the layout of my resume without risking losing my current resume.  
>
>There are many reasons why you would want to create a branch, but all the reasons always comes back to wanting to protect the master branch. Whether it's source code, your resume, or other files and folders you want to use with a version control system. 
>
>There are 2 ways you can go about creating a new branch in the project you have open. One way is to call on `git branch <new-branch>` then to `git checkout <new-branch>`. This is the 2 command step and with `git branch` you are able to view, create, modify and delete branches as required. `git branch` will also tell you what branch you're on with a `*` beside the branch name. This is important to confirm that you are on the right branch. Another extension of `git branch` is `git branch -r` which will show remote branches and `git branch -a` which will show all of your branches and all of the remote branches and have the `*` for the branch that you're on.
>
>> A tidbit for you is something I like to do if you're willing to experiment more with git: I set `git branch -a` to `git branches` using the `.gitconfig` file on your home directory. This may be a bit advanced for this tutorial but I wanted to show that the option is there. Something we can visit down the road, or you could [read this other blog post][42]
>
>The more condensed way of completing the creation of a new branch is to use `git checkout -b <new-branch>`. This tells git to create the new branch from where you are and check it out immediately. You will find that doing this is simpler than doing the 2 step method shown above but it's important to remember what exactly is being completed by using this one command to essentially run 2 commands. I also have to point out to you, that even after many years of dealing with git and using this command countless times, I still have to reference the manual page as I had forgotten the details over the years for `git checkout -b` and had to [reference it][41] again.
>
>Once you have created the branch and confirmed you are on that branch, you are good to make the change you are looking to complete. As you complete `git add` and `git commit`, you know you are applying those changes to the branch you created. Having the changes saved in its own branch is nice; say if you're working on a multi-day code update to the project, and you're looking to make sure your code is saved, you are going to add and commit multiple times through that period to save your code. 
>
>For those wondering, `git add` moves a copy of the code into your staging area before committing it using `git commit`. I know there is the command `git commit -a` which will just commit all of your changes immediately, although I do have to give you a warning that this could have detrimental effects on your code commits and it's better to take the time to add files accordingly before committing.
>
>Now that you have completed your change and ensured that everything is working as expected, you're going to want to merge into the master branch. The way this is completed is with `git merge`, but before you run that command you are going to want to make sure you check out the master branch with `git checkout master` and then run `git merge <branch>` as created above. As long as there has been no other branches merged in and changes done to the master branch, it should merge without any issues. However, if you come across a merge issue, you will have to run `git status` and fix each of the files listed as merge conflict(s). Once all the conflicts have been fixed, you are going to want to run `git add` for each of the corrected files, then `git merge --continue`. 
>
>Finally, after you have completed all the work you needed to do, and you no longer require the branch, you will want to perform some clean up on that branch. So, to complete this, you run `git branch -d <branch>` to remove this branch. It's always good to keep your branches clean from extra entries so you're not buried in a list of branches. 
>
>Additional notes for those new to this: I'm a firm believer in that you don't need to remember everything right off the get go with using git, but taking the time to remember where to look when you're stuck is important. So to help you out, I am going to share the links to every manual or man page for the git commands shown in this tutorial. Also, check out the git [pro git book][43] as it's free for everyone. I have read it and I find that I myself keep going back to it to look something up. 
>
>Manaul pages:
[git add][44]  
[git branch][45]  
[git checkout][46]  
[git commit][47]  
[git merge][48]
>
>A working example of the command in sequence
>```
`git checkout -b feature-branch`
`git add feature.txt`
`git status`
`git commit -m "awesome feature"`
`git checkout master`
`git status`
`git merge feature-branch`
`git status`
```  
>
>In summary, I hope you have learned something useful about utilizing git and if you have any questions, please ask in the comments section below. I or someone else will be able to assist when they see your question. 

[41]: https://git-scm.com/docs/git-checkout
[42]: https://about.gitlab.com/blog/2016/12/08/git-tips-and-tricks/#aliases
[43]: https://git-scm.com/book/en/v2
[44]: https://git-scm.com/docs/git-add
[45]: https://git-scm.com/docs/git-branch
[46]: https://git-scm.com/docs/git-checkout
[47]: https://git-scm.com/docs/git-commit
[48]: https://git-scm.com/docs/git-merge