Aims and objectives
For this self-initiated project, the aim was to learn version control via Git and GitHub and apply the knowledge to all my web projects. The main objectives were to:
- Understand the key Git commands for version control
- Learn the best practices for version control
- Use version control when developing the website for Room Four Dessert
Wait, Git and GitHub are not the same?
That is correct since Git is a version control system that keeps track of changes in files and GitHub is an online hosting platform for Git repositories. Git is primarily used for source code management, but since it can keep a track of changes in any type of file, the number of use cases are endless.
GitHub is like Instagram for developers as it enables others to view your submissions and provide their comments. It allows you to collaborate with others from around the globe with additional features such as bug tracking, feature request and wikis for any project. Although GitHub is ideal for developers, it can be used by anyone as it primarily serves as a hub for Git repositories.
So, what did you use?
Well, the most important part of the project was right at the beginning where I had to install Git, and I only needed to do this on my windows machine as Macs can already come with it pre-installed. I used the latest version Adobe Dreamweaver CC to develop my code since one of its new features of the program is the addition of Git version control via a simple GUI.
Once I started to understand the basics of Git, I shifted away from the GUI to get used to the command line, and to do this, I used Git Bash on windows and the Terminal on Mac. Since Git works locally, at some points of development, I would upload the local repository to GitHub via a push command.
Proof or it didn't happen
Ok, no problem, you can view all my public repositories on my GitHub profile. I began using Git for my portfolio right away and for my client's website, I used it from the ground up.
Ok how did you learn it then?
To learn the fundamentals of Git and GitHub, I watched many hours of online tutorials from Lynda.com, where the two courses I watched were Learning Git and GitHub by Ray Villalobos and Dreamweaver: Working with Git Version Control by David Powers. I also read a few short guides from GitHub guides to learn more.
As I was learning the basics of Git, I used Dreamweaver's built-in Git plug-in to get an understanding on how Git works, and once I felt comfortable with using it, I shifted to command line.
So, how did you use Git?
Initialising a repository
To start off using Git, I had to navigate to the folder where all my files were stored and then I ran a command to initialise Git.
Once initialised, a hidden folder called .git was created where all the files that Git needs to operate with are stored within here. At this point, it is good practice to create a .gitignore file, where a list of files and folders you don't want Git to track can be included, this is good for private data or system files.
Staging and commits
When files are created, modified and/or deleted, Git would acknowledge these changes, so next, I would essentially tell Git that I'm happy with the changes by staging the files and then committing it. I did this by adding the necessary files to the staging environment (where I can evaluate the changes and either proceed or go back) and commit it with a message. Then I ran a log command shows me the commit history for the repository, so I can see that the commits were made.
It is essential to add a message to commits as it allows myself and others to understand why the changes were made, which will make going back through the repository history a lot easier. If you would like to read more about why to add commit messages, I suggest reading this blog post by Petyo Ivanov.
Branches are a powerful feature of Git as it lets me continue working with version control without affecting other sets of code. In a blog post by Vincent Driessen, he explains that at the core, a good practice for branching is to keep the recent live version in the master branch and develop in a separate branch. This can be crucial when collaborating with others as when someone faces an issue, it will only affect their branch.
You didn't mention GitHub
Linking to a remote repository on GitHub can be done at any stage but it is good to do it near the beginning. So, once I had my local repository setup, I created a remote one on GitHub by naming it and setting it either private or public. From here, I used the remote command to link to the remote repository and then I used a push command to send my commits.
If I wanted to work from an existing repository, I can use the clone command to sync an existing repository to my local machine.
Once I had a link between my local and remote repositories, I was able to start using the push and pull commands. The push command sends commits to from the local repository to the remote one and the pull command does the opposite. When collaborating with others, it is good to use the pull command before working on files to ensure all your files are up to date, so you don't cause any issues further down the line.
So, what are your thoughts?
Overall, I believe this project was a success as I've come a long way, initially I looked at Git and thought, no way I could do this, it looks way too complicated. But thanks to the vast amounts of online guides and practice, I've been able to understand how to use it. This will prove useful to me in my career ahead as version control is widely used amongst developers.