What is version control?
According to Git's documentation on git-scm.com, "Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later."
Think of a video game. Like if you're playing Witcher 3, but you're not super confident that marrying the Werewraith is what Gerald should be doing. You save a checkpoint, marry the Werewraith, and then revert to the saved checkpoint once you realize the Werewraith was lying about having a level 10 Esterad Thyssen Gwent card.
In the same way, using Git, you can save your progress and then try out the craziest code ideas your mama told you would always lead to your ruin. And if they do in fact lead to your ruin, you can just go back to a different saved branch and pretend like nothing ever happened.
Saving your work in Git
The process of saving your work in Git is called a commit
When you are ready to commit, you will first need to make sure that the work you have done is saved within the folder in which you are working. You can either save using the dropdown file menu, or by hitting Ctrl + S on Windows, or Cmd + S on Mac.
Now you have to move the file to the "staging area". To do this, first enter git add <filename> in the terminal. This staging area can be very useful, but we're not gonna talk about that here, in this Very basic introduction.
The next step is to actually commit your changes. In the terminal, enter git commit -m "<your message here>". The message you put inside the quotes should be descriptive, so that you know what the committed version actually is.
$ git add index.js
// adds "index.js" file to the staging area.
$ git add .
// adds all files in current directory to the staging area.
$ git commit -m "added canVote key to user object"
// saves current changes as commit with the description "added canVote key to user object"
$ git commit -am "changed hea
// added all files to staging area and committed work in one fell swoop
And there you go! You've got a version of your work saved in the git repository.
Branches
A good way to try out some code without fully committing to any changes is through branches. Working with branches can be very complex, but here we will provide you with just an introduction.
Why use branches?
A branch will create a new path on which you can work to test out some code. Maybe you're trying out some wild stuff that you aren't sure you want in your main history, or maybe you are working with a group, but don't want to change the group's work just yet. You can make some changes on a new branch, which will not affect the history of the main branch. Unless you want it to. If you decide you would like to keep the branch as the main project, you can then merge back into the main branch.
Creating a branch
There are a couple methods for creating a branch. The first is to simply enter git branch <new branch name>. But if you would like to create the branch and immediately begin working in said branch, you can enter git checkout -b <new branch name>.
$ git branch newBranchName
// creates a new branch named "newBranchName". You continue to work in branch you were already in
$ git checkout -b newBranchName
// creates a new branch, "newBranchName". You are now working in newBranchName
Merging Branches
Let's say you're happy with your changes and are ready to make them an official part of your project canon. First you have to enter back into the branch, you would like to merge your edited branch into (let's assume it is main). Next you do a git merge command using git merge <branch name>. PRESTO. Your two branches have become one.
$ git checkout main
// switches back into the "main" branch
$ git merge newBranchName
// merges the branch "newBranchName" into the main branch.
OOPS! Take me back!
Oh my we've really done it this time. We've metaphorically married the proverbial Werewraith. Only chance at saving our program is going back to a previous commit. First, let us find the commit that we would like to go back to. You can do a git log command git log to see the commit history. Once you locate the correct commit (hopefully you created descriptive commit messages), you can do a Git reset using the commitID, git reset <commitID>, to return to that commit. Note that the default mode for a Git reset is a "mixed" reset, as opposed to a "soft" or "hard" reset. For more on this you can read this helpful guide.
$ git log --oneline
// shows the commit history, abbreviated to one line, making it easier to identify the correct commit
1410e61 third commit
f90d85f second commit
689fc78 first commit
// ^^^ this is the oneline log history. The seven character code is the commit ID, followed by the commit message.
$ git reset 1410e61
// resets to the "third commit"
Conclusion
The ability to try out new code or work on a group project without fear of potentially destroying everything you've already done, makes learning how to use version control with Git an extremely worthwhile effort. It's a valuable tool for any developer to have.
Top comments (0)