Git
Git is a version control technology of choice for virtually everyone, from developers to designers. Essentially, it means that it can track every modification you make to your code, for example. As a result, it has the benefit of allowing you to revert to a previous version that was working when you encounter errors in a novel feature.
The idea of a distributed VCS separates Git from any other version control systems. It has the benefit of allowing everyone to collaboratively have the updated history of the entire changes on their machine.
Changes can then be merged with the remote version. The overall benefit of this architecture is allowing different people to work on different novel features of the project concurrently.
Git is free, open-source version control software. It was created in 2005 by Linus Torvalds. It was initially developed to work with various developers on Linux kernel. It means that Git is a content crawler. Hence, Git can be used to store content, and it is mainly used to store code besides other functions. In general, several developers can work in parallel on real projects.
Github
GitHub is the most widely used project hosting platform today than any other. It’s a place where you can find and play with the most incredible open-source information, new technology, features, and designs. Further, it’s a place to learn and a suitable place to contribute to open-source projects.
There is no limitation to the kind of projects that you can save on Github. They are as diverse as you can imagine and range from projects on work or school work and personal projects for fun. You might bump into some wonderful projects that you might be interested in exploring further.
Overall, git is at the core of Github.
You need a version control system like Git to make sure there are no code conflicts between them, especially when working with more than one person on the same project concurrently. Besides, the requirements for these projects change frequently. Therefore, developers can roll back and revert to an earlier version of their code with a version control system.
The branch system in Git allows developers to work individually on a task. For example, One branch -> One task OR One branch -> One developer. Think of Git as a small software application that controls your codebase if you’re a developer.
Common Git Terminologies
Repo
The repository or repo is a collection of all the project files in a folder. It also contains all the necessary history of the changes made to the given file.
The common repo’s include:
Local repo – This is the replica of your remote project that is locally hosted on your machine. All the changes you make while working on your project on your machine are stored in the local repo. However, if you want your collaborators to view the changes you have made, you simply push to the remote repo.
Remote repo – This is the repository that is hosted on Github. It is remote because you can access it from anywhere besides your local machine.
Init
git init is the first command if you want to instruct git to start tracking your project. The resultant is a hidden .git directory that stores data on the internal structure that is needed by the version control.
git init
Cloning
Cloning is the process of making a copy on your local machine of the remote repository. It allows you to work on the project locally at your own pace.
The command to accomplish this is git clone
git clone <url for the repository>
Add
After making the necessary changes to your project, add the files you have made to use the git command add to the staging environment. There are various variations of add command, mostly differentiating the kind of files that you want to be registered on git. For instance, to add all the files that you have made changes on, use the command,
git add .
On the other hand, if you want to register a specific file only, pass the file’s name instead of the dot. For instance, if the file I made changes on is named index.html, then my command will vary as follows:
git add index.html
Commit
After adding files to the index or the staging environment, it is time to save a snapshot of the history of that project. This, in turn, completes the tracking process for the changes. For example,
git commit -m "initial index file commit hkm"
Push
Use the push command to move the changes from your local repository to the remote repository. By transferring your local changes to the remote repository, the new updated changes will be available to all the members collaborating on that project.
git push origin <branch name>
In the above command, remember to pass the correct branch. For instance, if you intend to push your changes to the staging branch, then the complete will appear as follows.
git push origin staging
Pull
When you intend to access the changes on the project that your colleagues have already worked on, you need to use the pull command to get the changes. The pull command will simply transfer all the changes from the remote repository to your local machine.
git pull
Status
If you intend to have a preview of the state of your project, then the status command is extremely vital. It allows you to show the status as either modified, staged, or untracked.
Ensure that you are at the root of the repository and run the following command.
git status
What are the common git states?
Git states are primarily three. They include staged, modified, and committed. So, at any given time, your project’s files are in one of those states.
Modified – this is the state when git has changed files, and it has not marked those changes. At no given point can these files be part of the snapshot coming up.
Staged – These are the changes that git will mark in the following snapshot because Git can track these changes.
Committed – These are the files that are officially part of the recent snapshot.
Branch
The git branch command shows all the branches available on your local repository. Subsequently, it uses the asterisk sign(*) to show the currently active branch.
git branch
Merge
Git merge command is important when you intend to merge changes from one branch to another branch. For instance, if I am working on a feature branch and intend to merge the completed changes to the staging branch, the git merge command comes in handy. First, switch to the staging branch then run the following command.
git merge feature_branch
Forking
Forking someone’s project usually means having a copy of their project on your account. This concept is very useful when you bump into a project that interests you and you would like to contribute to it. So, after having your local copy, you can work on the changes that interest you. Then you can create a pull request so that the owner of the repository can review your changes. If they like what they see, they can merge the changes on the main project. That is the beauty of open-source software with people from different walks of life collaborating on very interesting ideas.
The second use of forking that we find useful is exploring other people’s projects. At one point or another, you will find something that captures your eye and just wants to play around with it. Don’t tarry; fork is there for you!
Step 0: Install Git and create a GitHub account
The first two things you need to do are install Git and create a free GitHub account.
Installing Git on Linux
If you want to use the binary installer to install essential Git tools on Linux, you can usually install it using the package management tool that comes with the distribution. If you are using Fedora or a closely related RPM-based distribution such as RHEL or CentOS, you can use DNF:
tuts@codeunderscored:~/Documents/git/tuts$ sudo dnf install git-all
If you’re on a Debian-based distribution, such as Ubuntu, use apt:
tuts@codeunderscored:~/Documents/git/tuts$ sudo apt install git
Installing on Windows
There are also several ways to install Git on Windows. The most official version can be downloaded from the Git website. Just go here. Then choose the options windows, and the download will start automatically. You also have the alternative to 32-bit or 64-bit versions or even the windows portable version. The latter version is sometimes called the thumbdrive edition.
Step 1: Create a local git repository
When you use git to create a new project on your local computer, you need to create a new repository. First, open the terminal and use the cd (change directory) command to navigate to the location where you want to put the project on your local computer. For example, if you have a project folder on your desktop, you should do the following:
cd tuts@codeunderscored:~/Documents/git/tuts
To initialize a git repository in the root of the folder, run the git init command:
git init
Step 2: Add a new file to the repo
Go beforehand and upload a brand-new record to the project, using any textual content editor you want or use the touch command to create and save a file called newfile.txt.
Once you’ve delivered or changed documents in a folder containing a git repo, Git will keep track of that record within the repo. Git will most effectively save/manage adjustments to documents that it tracks.
tuts@codeunderscored:~/Documents/git/tuts$ touch newfile.txt tuts@codeunderscored:~/Documents/git/tuts$ ls newfile.txt
After creating the new file, you can use the git status command to see which files git knows to exist.
tuts@codeunderscored:~/Documents/git/tuts$ git status
Output:
from the output, the resultant checklist indicates:
- the branch you are currently working on
- commits, for instance, ‘No commits yet.’
- Untracked files, which lists the files and hint on what to do to have them included in what should be committed.
At the bottom, there is usually a general message, especially for the first time. In our case, it indicates that nothing has been added to commit and affirms the presence of untracked files. The message mentions using ‘git add’ to track the files not yet tracked.
Step 3: Add a file to the staging environment
Add a file to the staging environment using the Git add command.
tuts@codeunderscored:~/Documents/git/tuts$ git add newfile.txt
If you rerun the git status command, you’ll see that Git has added the file to the staging environment, as shown in the diagram below.
tuts@codeunderscored:~/Documents/git/tuts$ git status
Step 4: Create a commit
It’s time to create your first commit!
Run the command git commit -m “Your message about the commit.”
For instance,
tuts@codeunderscored:~/Documents/git/tuts$ git commit -m "added newfile.txt to initial commit hkm"
Step 5: Create a new branch
For example, suppose you want to create a new role, but you are worried about making changes to the main project while the position is being developed. That is where Git branches come into play. You can use branches to navigate between project states.
The official Git documentation describes branches as follows: “A branch in Git is just a lightweight pointer to one of these commits. ‘Run git checkout -b. This command will automatically create a new branch and then check it out. The latter means that Git will move you to the new branch other than the main branch.
After running the above command, you can use the git branch command to confirm that your branch has been created:
tuts@codeunderscored:~/Documents/git/tuts$ git checkout -b new_fosslinux_tuts
Step 6: Check Braches that are locally available
If you wish to look at the branches you have locally on your machine, run the following command.
tuts@codeunderscored:~/Documents/git/tuts$ git branch
From the diagram above, there are two branches, but the currently active branch is new_fosslinux_tuts.
Step 7: Creating a new repository on GitHub
If you want to track the code locally, you don’t need to use GitHub. However, if you want to work with a team, GitHub can help manage the project code collaboratively. To create a new repository on GitHub, please log in and go to the GitHub homepage.
You can find the “New Repository” option under the + sign next to your profile picture in the upper right corner of the navigation bar:
Step 8: Push a branch to GitHub
Now, we move the branch commit to the new GitHub repository. It allows others to see your changes. If approved by the owner of the repository, the changes can be merged in the main office. To push changes to a new branch on GitHub, you need to run git push origin <yourbranchname>. GitHub will automatically create a branch for you in the respective remote repository.
tuts@codeunderscored:~/Documents/git/tuts$ git remote add origin https://github.com/Chemokoren/tuts_fosslinux.git
tuts@codeunderscored:~/Documents/git/tuts$ git push -u origin main
After running the above command, you may encounter an error like the one below. error: failed to push some refs to ‘https://github.com/Chemokoren/tuts_fosslinux.git’
To resolve this error, run the following counter command.
tuts@codeunderscored:~/Documents/git/tuts$ git branch -M main
Subsequently, run the push command again as follows.
tuts@codeunderscored:~/Documents/git/tuts$ git push -u origin main
Step 9: Creating a pull request (PR)
A pull request (or PR) is a way to alert repo’s proprietors to which you need to make some modifications to their code. It lets them study the code and make sure it looks precise before setting your alterations at the number one branch.
On the menu, select pull requests. Then set your main branch where you intend the changes to be merged as the base branch. In our case, this is ‘main.’ Also, set the new branch with new changes as the compare branch. In our case, this is the creating_PR. When you can confirm a green tick to the right of the compare branch with the words, ‘Able to merge,’ go ahead and click on the button to create a pull request.
Open a pull request
On the new window that appears, you have the option to enter your comments about the changes pushed on the new branch. These comments should be definitive of what the changes are about. They should be clear, concise, and communicative.
Finally, click on create a pull request at the bottom right of the window. Here, you can also opt to create a draft pull request which will only be merged when you finally complete it and mark it ready for review. For this demo, we will opt to choose one. This pull request is ready for review now.
Step 10: Merging a PR
Go ahead and click the green ‘Merge pull request button.’ The latter will merge your changes into the primary branch. Ideally, this should be done by another collaborator who reviews your changes. While doing the review, they can merge your changes if they are OK, or they can revert them to you with their comments on what you need to modify.
This happens at the bottom section, where the review can write their comments and click on the green button ‘comment.’ The branch owner can then make the necessary changes and update the original pull request with the needed changes.
Finally, it is time to merge the pull request after all the back and forth between the reviewer and the creator of the new changes.
At this point, the review has three options
- Create a merge committed
- Squash and merge
- Rebase and merge
Creating a merge commit
All the respective commits on the given branch are added to the main or base branch through a merge commit with the aid of the initial pull request created.
Squash and merge
Here, only the 1 commit from the given branch is added to the base branch specified earlier.
Rebase and Merge
It involves the single target commit from the given branch being rebased and subsequently added to the base branch.
In this demo, we will go with the first choice involving the creation of a merged commit.
Finally, click on confirm the merge. Or if you choose, you can cancel, especially if you remembered a new change that you need to make.
If the process is successful, you will get a success message indicating that the process completed successfully, as shown below.
Step 11: Get changes on Github back to your computer
Currently, the remote GitHub repository looks different from the one on your local computer. The difference is that the commit made on the branch and merged with the main branch does not exist on the local computer’s main branch. Use the Git pull origin master command to fetch the changes you or others have accumulated on GitHub. In most cases, it can be shortened to “git pull” if you are at the root of the parent repository on your local machine.
First, we will switch from the branch ‘creating_PR’ to the main branch by running the following command.
tuts@codeunderscored:~/Documents/git/tuts$ git checkout main
Finally, run the command git pull to fetch the new changes from the remote repository.
tuts@codeunderscored:~/Documents/git/tuts$ git pull
You’ve successfully made a PR and merged your code to the primary branch.
Summary
To use Git, developers use specific commands to copy, create, change, and combine code. These commands can be executed directly from the command line or graphical user interface applications like GitHub Desktop and GitKraken.
The common commands we have looked at that every git user should master while using Git include:
• git init- Initialize the new Git repository and scan the existing directories
• git clone- similar to downloading an online repository to a local folder
• git add – stages a change
• git commit- Save the snapshot in the project history and complete the change tracking process. In short, confirmation is like a photo. Everything prepared with git add will become part of the git commit snapshot.
• Git status – View the changed status as untracked, changed, or incremental.
• Git branch- shows the branches being worked on locally.
• Git merge – merges lines of development. This command is typically used to combine changes made on two distinct branches. For example, developers would merge when they want to combine changes from a feature branch into the main branch for deployment.
• Git pull – updates the local repository of development with updates from its remote counterpart. Developers use this command if a teammate commits to a branch remotely, and they would like to reflect those changes in their local environment.
• Git push – updates the remote repository with any commits made locally to a branch.
