Mastering Git: An Introduction to the Fundamentals
Git is a distributed version control system (DVCS) for tracking changes in source code during software development. Linus Torvalds designed and developed it in 2005 for Linux kernel development.
Ok, hold up; what is a distributed version control system?
Version control is a system that allows you to track changes made to a set of files over time.
One of the critical features of git is that it is a distributed system, which means that each developer has a complete copy of the entire codebase, including all its history, on their local machine. Git allows developers to work offline and provides redundancy and protection against data loss. Git allows multiple developers to work on the same codebase simultaneously and tracks changes made to the files over time. It also allows for easy collaboration and code-sharing between team members, with features such as branching and merging. Git allows for multiple versions of the codebase to be maintained and for changes to be easily integrated into the main codebase when ready.
Using version control has many advantages, including:
- Keeping track of changes: It allows you to see who made what changes and when and why they were made.
- Collaboration: It allows multiple people to work on the same project simultaneously and makes it easy to merge their changes.
- Rollback: If something goes wrong, it’s easy to roll back to a previous project version.
- Experimentation: It allows you to experiment with new ideas without worrying about breaking the existing code.
How do I use git?
Save this list ->
the basic git commands are:
git init — is used to initialize a new Git repository.
git add — is used to add changes in the working directory to the staging area.
git commit — is used to save changes from the staging area to the local repository.
git push — is used to send commits from the remote repository to a remote repository.
git pull — is used to retrieve and merge changes from a remote repository to the local repository.
git fetch- is used to retrieve new commits from a remote repository without merging them.
git clone — is used to create a copy of a remote repository on the local machine.
git status — is used to check the status of the files in the working directory, including changes that have been made but not yet committed.
git branch — is used to list, create, or delete branches in the repository.
git checkout- is used to switch branches or restore working tree files.
git merge — combines changes from multiple branches into the current branch.
What is the basic workflow?
The code will be in a repository, and the most common git repository hosting providers are: Git Hub, Bitbucket and AWS code commit once added to this repository. Your first step will be to clone the repository from the origin to your local machine.
Once this command has finished running, cd into the new directory you created.
Your next step will be to create a branch and check out that branch.
Git uses branching to isolate your work and changes from the main source code. There are different stratagems for branching, one of most common is called feature-branching.
Now let’s make some changes to our branch and save them.
We can do git status, showing us all the files we have changed.
We can do a git add <file-path>, or you can do git add . to add all files. These commands would add the files to the staging area. The staging area is your holding area for your changes before you push them to the remote repository.
If by some chance you made a mistake and wish to un-stage a file, you can do git reset <filename>, and it will remove the file from the staging area.
Once you are satisfied with the files in your staging area, you’re ready to do your first commit.
git commit -m “<your-commit-message-here > ” optionally, you can add a description with more details by doing git commit -m "your short commit message” -m “your more extended, more detailed message."
Optionally you can do a git status to see if you missed any files you need to add.
If everything is correct, you are ready to push your files to your origin.
The easiest way to do this for the first time is git push
This command will fail because we have not set our upstream remote. The error message will give you a handy hint.
Let’s copy the hint from the error message to set the location of our branch’s remote origin.
git push --set-upstream origin <my-branch-name>
Now you are done, and your files are in the remote; congratulations!
After pushing your files, you find out your co-worker has added some changes to the main branch that you would like on your branch so you can continue working on your feature.
There are two options for adding these changes to your branch; git merge and git rebase. There are advantages and disadvantages to both methods.
git merge is used to combine multiple branches in git. When you use git merge, it creates a new commit on the branch you are working on, which includes all the changes from the branch you are merging — making a linear history, with the recent commit acting as a “merge point” between the two branches.
git rebase is used to move or “rebase” a branch to a new base commit. You can incorporate changes from one branch into another without creating a new merge commit. Instead, you add the commits from the rebased branch to the top of the new base; hence the term rebased. Rebasing leads to a cleaner and more linear history.
You should use git rebase when you want to integrate changes from one branch into another and preserve a linear history. Git rebase is useful when working on a feature branch based on a main branch (such as main), and you want to keep the feature branch’s history clean and easy to follow.
On the other hand, you should use git merge when you want to combine the changes from one branch into another and create a new merge commit. Git merge is proper when you want to preserve the entire branch history, including the merge commit, and show that the changes from the two branches were combined.
It is also important to note that git rebase can cause conflicts if the branch you are rebasing has commits that conflict; with the commits on the branch, you are rebasing onto. Often this happens when more than one person is working on the branch. In contrast, git merge automatically creates a merge commit that records the conflict resolution.
In summary, git merge creates new merge commits in the history while git rebase moves the entire branch to point at a new base commit, leading to a linear history.
Thanks so much for reading. If you enjoyed this crash course in Git, please hit the follow button.
