I have sometimes wanted to throw the computer across the room when trying to figure out Git, but I found some good tutorials! I’ll put the links at the bottom of this post.Â Not only did I find helpfulÂ tutorials, but I want to put some of what I learned about the Git commands into “non technical terms”.
Git is used to help you organize backup copies of your program. Every time you commit a copy of what you are working on, it is like saving a copy of your document/project. Typically you do this every time you’ve added something or worked on something. All the previous saved versions of your projectÂ (or whole program directory, called a repository,) still exist, and you don’t Â have to keep making incremental file names the way I usually do. And before you save your file, you can look at the differences you’ve made since the last time you saved.Â Status will check to see Â which files are staged to be saved (commit).
I end up with a big directory full of confusingly-namedÂ copiesÂ like HorseFridayA.PSD, HorseFridayB.PSD, HorseFridayB2.PSDÂ as I am working on an Adobe Photoshop file,Â for example. But with Git, your current save contains a log of all the changed versions you’ve made in the past! So if you need to go back and undo something, you have all those undo-states available.
Not only can you see a log of all the changes you’ve made, if you want to go back to a previous version and then “try something different and crazy that may not work” you can clone the project and make a branch. In the branch you canÂ create a second version of your project. Then you can work on that version. And if you end up liking those features and wanting to add them back into the original version, you can merge them back together. Handy!
But another majorÂ reason people use Git is this: when you upload your project repository to GitHub other people on your team can make changes and work on the documents at the same time you are in them. Then you can update and merge them all back together. Git will warn you if you have made conflicting changes, and you can resolve them before you merge. And you can see the differences between what you did to your copy of the file, and the other team member did.
You can even use GitHub toÂ fork and make a copy of another person’s code repository and alter it to do the things you’d like it to do. You can pull that copy down to your local computer, make changes and push it back.
So Git and GitHub are powerful and useful, once you knowÂ what they are for! I still don’t exactly understand why the command line is favored over a graphical interface, but it is, and “they” say you will find it great after you get used to it.
Â Ok, now for the tutorial links. These are some I found especially clear and easy to follow:
Making the command prompt easier to use: