A Brief on GIT
The last commit is every developer’s nightmare, especially for those who aren't sure about the feature they are trying to build and for those who are not confident with their code. And for others, it is the merge conflicts. Most of them are confused why their code has so many review comments.
There are two kinds of developers, 1. The ones who don’t (know how to) use GIT efficiently(I was one of them), 2—the ones who are very meticulous with versioning and use GIT religiously(I am trying to stay put in this club).
What is GIT?
There are many versioning software; the most commonly used is GIT. Using GIT helps to version control the codebase. Coordinating with developers becomes more effortless and saves time with the blame game(It can get ugly, trust me). You can find many different cloud hosting repositories like BitBucket, most commonly used by larger organizations.
Need for GIT
As the team expands and the idea of common code == makes things easier persists, meticulous care is needed while adding code to the repository.
With most organizations following the AGILE software development process, using GIT helps maintain some sanity in the team. GIT supports a faster release cycle. Stable builds are essential for continuous development.
The branching capabilities of GIT are the most helpful for developers. These are easy to merge(Easy only when people rebase and remove all conflicts.)It helps to roll back easily and helps in maintaining a stable version.
Distributed development is the key to successful releases. The dependency over one another is reduced drastically and helps in parallel development.
Some Common Terminologies
Pull Requests
Developers call this PR. Pull requests are the core part of developing sustainable code(Blame the guy who approves the PR. JK!) Pull request is when a developer asks his teammates(usually senior developers, but peer reviews help a lot too!) to review their code to achieve good coding practices and make sure there are no trivial errors that can cause nightmares later.
This process helps in not breaking the working code. You can find overly enthusiastic egoistic developers who believe their code is as beautiful as them but later realize not everyone appreciates it. My code has broken a working version because the lead was too busy to review the code. This is why you require more than two reviewers, and both should approve.
Branch
GIT branch is used to list all the existing branches, add/delete branches. In simple words, the branch is used to clone the code in the parent branch to a new branch. The content is the same in both branches. Each developer creates a new branch for new features and defect fixes in most teams. This process of creating new branches helps in keeping the Master or the release branch stable. A simple illustration is shown below. The branching technique helps in the parallel development of features, maintaining a continuous delivery. Since the story/feature is independent, the only thing to keep in mind is to merge the branches efficiently.
Add
GIT add is used to append the changes in the branch to the staging area. In common terms, the operation is very similar to saving. The changes are saved and are not recorded. This command needs to run every time there is a change made. The staging area is where all the modifications are recorded until the commit command is run.
Status
GIT status is the list of changes in the staging area. GIT status is a handy command which is rarely used to its fullest. It lists all the files added to the staging area using the add command. It also lists the files which are deleted. It informs about the untracked files which are added to the staging area. These are the beautiful minutes after GIT pull, and nobody understands why there are a gazillion files in the staging area! The best use of this command is to check if the working tree is clean and the list of files that are to be committed. It also doesn’t have a commit history. The changes are not tracked. Few intelligent souls love pushing the code before committing(I used to be this intellectual soul, haha).
Stash
The development process can get messy. If there is a need to switch to another branch but not commit the half-done work before switching, GIT stash is a lifesaver! Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch). Adding messages to the stash helps to understand what code was stashed.
Clean
GIT clean is used to eliminate the files or changes in the working directory, which are stashed. The command removes the files from the working directory, which are untracked. The files cannot be retrieved after running GIT clean.
Commit
GIT command captures the snapshots from the staging area. GIT will never make changes to the changes. Just as the staging area is a buffer between the working directory and the project history, each developer’s local repository is a buffer between their contributions and the central repository. The advantage of commits is that they can be atomic in size, group all the commits, and clean the local history before publishing the code to the central repository. It is encouraged to keep the commit size as small as possible to control the changes. Writing messages with every commit is essential because it helps keep track of the commits and review the code quickly.
Push
GIT push is used to upload the local repository to the remote repository. This command is used when the developer is ready with all the commits and is prepared to move the changes to the remote repository. There could be a lot of conflicts if you are unlucky. If the day is smooth, you could have very few conflicts!
Merge
GIT Merge is used when changes from one directory are combined with the working directory. Merge unifies all the commit history from the two branches.
Pull
GIT pull is the most used command any developer would type in her/his terminal. This command is generally used to pull the latest changes from the new commits. Now, if you have been working on a branch and the changes are not committed, GIT pull can overwrite your changes with the latest commits. In general, GIT clean can be used two to three times to keep the branch in sync with the Master. There are other ways to sync the branch and Master, but this is a trivial way. Most junior developers end up struggling after GIT pull because either their changes are overwritten, or they end up breaking their head with conflicts!
You can find the commands of all these features of GIT in the GIT tutorial.
Rebase
GIT Rebase is a helpful command. It is used only when the tech lead asks to use it because half of the developers waste their time solving conflicts after GIT pull. Rebasing combines the commits from the parent branch and adds them to the top of the current branch. Rebasing is changing the base of the current branch from one commit to another, making it look like the branch created is from a different commit. Even though the branch looks the same, it is composed of new commits and older commits. This helps to have similar commits as the Master. Merge conflicts become easier to solve while merging the branch.
Comprehending GIT is very important for a software engineer. Most of the junior developers struggle to embrace GIT. Even if the project small and has less than three developers, GIT should be a crucial part of the development process. There are many times where the entire file is replaced instead of adding and committing using GIT. Good practices lead to good products and smooth production release. I have seen leads breaking their heads to fix bugs without proper commit messages and GIT practice. To sum it up, use GIT to the fullest to be at peace.
You can start by creating an account in Github and practicing these commands with all your projects.
References
All possible web pages containing information on GIT.
