What is Git?
Git is an open-source Version Control System (VCS) created by Linus Torvalds, creator of Linux, in 2005. It is mainly used for collaboration in a programming project. Hence, it provides a version control system where you can commit a certain version of your project so you can go back and forth between version histories. It also supports non-linear development with branching and merging, distributed development where you store your code remotely and locally, cryptographic authentication, and a lot more! With git, you can easily synchronize your work with your coworkers independent of time and space.
How the Git?
A picture worth a thousand words eh? Here’s an example of a Git workflow.
Imagine this as a timeline and every dots is a certain version of your project. When you start a Git project, you first start with a single timeline called branch. That branch is like the main branch of your project where every other branches start and should ends to (not necessarily). In this case, our main branch is called Main.
Now, at a certain time you want to record the current version of your project as a dot like in the picture, it’s called commit. Every branches starts from a commit and in this case, Little Feature and Main starts from the first commit and Big Feature starts from the third commit. Usually, you want to create branches for separation of concern, i.e. your own feature separated from your coworker.
When you’re done with your branch you should merge your branch to other branch to synchronize, that’s called merge. You could also just use your single branch to synchronize, but it’s just a matter of best practices that wouldn’t create hassles in the future. We’ll get to that latter.
Typically in a workflow there are two other versions of your code that exists; local which is stored in your computer, remote which is stored remotely in a cloud repository platform like GitHub or GitLab. When you want to upload commits to remote repository, it’s called push. Don’t get to overwhelmed yet with that last picture! Just keep that in mind when we try out git.
Why the git?
You must be thinking, why do I need all of this? I have the power of Google Drive and project-final-final-not-kidding-final (69) in my hand! Welp, git doesn’t just do version control like you overuse the final word, it provides important stuff when you do a programming collaboration:
- Robust version control, where you can get back and control any point of commit you want. Not just within yours, but also others!
- Built in synchronicity, where git will do the merging and conflict resolution magically out of the box. When some conflict do happens, git will assist you to merge the conflict yourself.
- High integrity, where your versions is saved using hashes and cryptographic functions for commit verification so no one can tamper with it. This also to keep track the relationship between commits and branches.
- The Zen of asynchronous collaboration, where you can focus on your feature first and synchronize latter, independent of space and time, using the internet via remote repository.
There’s also some important features provided by the remote repository platform like Continuous Integration/Continuous Development, etc., but that’s outside our scope of discussion. Let’s just now focus on the git gud part!
How to git?
Now this is the fun part! Now I’m gonna demonstrate how to create repository remotely via GitLab, but keep in mind that it’s not necessary. I’ll tell you which part it is that you can create locally. Also, steps
Step 0 Install git
Of course! You need to install git first. Go to https://git-scm.com/download/ and install necessary files.
Step 1 Go to gitlab.com and create a repository.
This is the optional part. If you don’t want to create a remote repository, you can skip to step 2.
After you register to gitlab.com, in the dashboard click “new project” or go to https://gitlab.com/projects/new to create a new project. Then choose “create blank project”. Then fill in the forms.
Note to not check for initialize repository with a README. This is because we’re going to create first commit locally and avoid conflict when we want to push to remote. When you’re ready, click “create project”, you’ll be redirected to the created repository page.
As you can see, gitlab already provide us with some commands to start with locally. You need to keep note of that commands for us to use later!
Step 2 Create a local repository
Go to your project folder and open up a terminal. If you don’t have a project yet, just create an empty folder and fill it with some files.
If you created a remote repository, paste git global setup into the terminal. For example for mine:
git config --global user.name "I Gede Aditya Premana Putra"
git config --global user.email "i.gede97@ui.ac.id"Now, whether you create a remote repository or not. Create a new local repository with git init. The option — initial-branch=main will create main branch named main. It’s optional and git will automatically name the branch with the settings you have locally.
git init --initial-branch=mainNoice! you’ve created your first repo.
Step 3 Commit and Push
Start by staging your files.
git add .This command will stage all files in your repository. You can stage certain files only by replacing . with the path to your file.
If you remember the git data transfer image from previous. There are 4 environments in a git repository; working directory, staging, local repository, and remote repository. Before we stage files, we’re in the working directory environment. Now we’re in staging environment where files are ready to commit.
Next, commit your files.
git commit -m "Initial commit"Now we’re in the local repository environment where the commit is stored locally. The -m “Initial commit” part is the commit message to describe what commit it is. Keep it simple and describe what changes have been made relative to previous commit.
If you created a remote branch, you want to push the branch to it. Copy paste the Push an existing git repository command to the terminal (excluding the cd existing_repo part if you already in your project folder). Or if you didn’t take note…, you can look mine:
Important note: If you don’t remember to submit ssh public keys, or don’t even know what it is, replace the
git@gitlab.com...with the link to your repository.
git remote rename origin old-origin
git remote add origin https://gitlab.com/gadityap/git-gud
git push -u origin --all
git push -u origin --tagsNow go to your remote repository and you’ll see your commit message and some files have been uploaded.
Congratulations! you’ve pushed your first repository. Now we’re in the remote repository environment where commit stored in remote repository. Try this command and see your commit message locally.
git log
Now this is where the cycle begins, after you’ve made your changes to a file and ready to publish the changes, remember the magic spell; git add, git commit, and git push.
More to Git?
Surely if you just using it with only add, commit, and push you’re not unleashing the full potential of git. Here are some more use of git.
git status
Use that command to see unstaged files, staged files and current branch.
git pullUse that command to pull changes from remote. There might be some conflict that you need to resolve on your own. With that, git already provide you which part of incoming changes and which part of current changes in the conflicting files, you just need to choose which one to keep, or even both.
git branch <branch_name>
git checkout <branch_name>That command will create a new branch based on current branch and set the current working branch (checkout) to <branch_name>. You can simplify that command with git checkout -b <branch_name>.
git push -u <branch_name>After you create your new branch and start committing, that command will push your new branch to remote repository. The -u option will bind the remote branch to the local branch. This is only needed once and you can omit that in the next push.
git merge <branch_name>You can merge another branch to current branch. For example with above command you’ll merge current branch with <branch_name>.
git revert
git resetThe above first command will revert certain commit you choose. Reverting will actually create a new commit with the changes being reverting the chosen commit. Contrast to reset, it will literally delete all commits from current to chosen commit. It is recommended to only use revert as to preserve the commit structure and also avoid conflict when synchronizing with remote.
git stash
git stash popUse above first command when you want to stash your unstaged changes. Stashing is useful when you want to change or merge branch and want to store unstaged changes somewhere else. Use the second command to apply stashed changes.
git log
Lastly, with above command you can see the commit history of current branch.
Git Gud!
Now this is the crucial part. To get good into doing git you must also understand the best practices. Here are some best practices that you should follow.
Short and concise commit message. A commit message should be shorter than 50 characters and describes the changes that have been made. Don’t write random stuff like something, hehe, aaaa, etc.
Use branching to separate features. As we’ve discussed earlier, branching is used for separation of concern and usually to separate developer working timeline. The gotcha thing when you only use one branch for all features is when you or your coworker synchronize each other, every time you push you need to synchronize. That will create the hassle of pulling and merging from remote to local every time you want to push, thus will increase the chance of merge conflict. This is bad because it will disturb your development flow. You generally want to synchronize at one time when you finished your feature or need certain feature from the parent branch.
Commit often. Now, this one is a sort of a hassle itself, I feel it. But the purpose of this is to create detailed history of your project. Maybe at some time, you want to revert a feature. If that feature is committed with other feature, you don’t have any option to also revert that feature.
Don’t alter published commits and branches. It’s really advised when you’re working with many people. Altering published commits and branches will result other people receiving conflicts. That will just create a hassle to everyone else working with the remote repository.
Don’t commit generated files. Now this is important. If you found committing generated files is unnecessary, then don’t do it. Some generated files will have a large size like binaries and downloaded libraries. Thus when pushed, it will create a burden to all of the remote repository users. You can use .gitignore to ignore certain files in certain paths. You can read more of it here.
All of those are more like of suggestions rather than rules. An experienced gitters will adapt when met with edge cases. For example, when you need to want to publish your repository to the public and want conceal some of commits that contains critical information, or some accident happens, you can use git rebase for that. You see, these best practices are important, but what is more important is that you can adapt and chose the right decision.
Conclusion
Congratulations! Now you’ve became a git master. There’s still a lot of what you can do with git like rebasing, creating release tag, etc. But, my hands are getting tired so I think we can end it here. You can read more about git commands at their online documentation here. Have a nice gitting!
