If you're a software developer, chances are you're already familiar with <a href="https://git-scm.com/" target="_blank">GIT</a>, the popular version control system used by teams all over the world. But even if you've been using GIT for years, there may be some tips and tricks you haven't discovered yet that can help you work more efficiently and effectively. In this <a href="https://cyberlab.rs/blog" target="_blank">blog</a>, I'll be sharing some of my favorite GIT tips and tricks that I've learned over the years.

 
Some of these tips may be well-known to <a href="https://git-scm.com/" target="_blank">GIT</a> experts, while others may be lesser-known gems that can make a big difference in your daily workflow. Whether you're new to GIT or an experienced user, I hope you'll find something useful in this post. So without further ado, let's dive into some of the most useful GIT tips and tricks out there! 

<h2 style="text-align: justify;">GIT merge vs GIT rebase </h2>
Command git merge and git rebase are two ways to integrate changes from one branch into another. Command git merge combines the changes made on one branch with the changes made on another branch. It creates a new "merge commit" that has two parent commits, one from each branch. This creates a new snapshot of the codebase that includes changes from both branches.&nbsp; Command git rebase, on the other hand, moves the changes made on one branch to the tip of another branch. It essentially rewrites the branch history, making it look like the changes were made directly on the other branch. This creates a linear history that may be easier to follow, but it can also create conflicts if the same changes were made on both branches.




 
<img src="https://cyberlabimages.s3.eu-central-1.amazonaws.com/Untitled+design.png" style="width: 700px; height: 467px; display: block; margin-left: auto; margin-right: auto;" alt="GIT Tips and Tricks">
 
 
<h2 style="text-align: justify;">Git reset</h2>
In Git, "reset" is a command used to undo changes made to a repository's commit history. The difference between a "hard" and "soft" reset lies in the level of undoing that occurs.
 
<pre style="text-align: justify;">git reset --soft HEAD~1&nbsp;#&nbsp;reset&nbsp;soft last commit </pre>

 A "git soft reset" does not completely remove changes made in a specified commit. Instead, it simply moves the&nbsp;HEAD&nbsp;pointer, which determines the current working state of the repository, to the specified commit. This means that changes made after the specified commit are still present in the repository and can be accessed and modified. Soft resetting is useful in cases where a developer wants to undo a commit but still retain the changes made in that commit, such as when a commit needs to be reworked before being added back to the repository. 

<pre style="text-align: justify;">git reset --hard HEAD~1&nbsp;#&nbsp;reset&nbsp;hard last commit </pre>

 On the other hand, a "git hard reset" completely removes all changes made in a specified commit and resets the repository to that point in history. This means that any changes made after the specified commit will be permanently lost. Hard resetting is useful in cases where a developer wants to completely remove all changes made in a commit, such as when a commit introduces a serious bug that needs to be completely removed from the repository. 

<h2 style="text-align: justify;">Git amend </h2>
<pre style="text-align: justify;">git commit --amend&nbsp;# change last commit git commit --ammend -no-edit #change last commit, same commit message </pre>
 In Git, "amend" is a command used to modify the most recent commit in a repository. Specifically, "git amend" allows a developer to make changes to the commit message or to the files that were included in the most recent commit. When a developer runs "git amend," Git will open the default text editor with the commit message for the most recent commit. The developer can then make changes to the message, save the file, and exit the editor. Git will then create a new commit object with the same parent as the most recent commit but with a new message. The new commit will replace the old commit in the repository's commit history. In addition to modifying the commit message, "git amend" can also be used to add or remove files from the most recent commit. To add files to the most recent commit, a developer can simply stage the files using "git add" and then run "git amend" To remove files from the most recent commit, a developer can run "git reset HEAD~" to unstage the files and then run "git commit --amend" to create a new commit without the unwanted files. 





<h2 style="text-align: justify;">Git logs </h2>
<pre style="text-align: justify;">git log git show -- &lt;filepath&gt; </pre>
 <a href="https://git-scm.com/" target="_blank">Git</a> logs are incredibly useful for developers because they provide a detailed record of all the changes that have been made to a repository over time. Here are a few reasons why Git logs can be particularly helpful: 
<ol style="text-align: justify;">
 <li style="">Understanding the history of a project: By running "git log" command, developers can see a chronological list of all the commits that have been made to the repository, along with the commit message and the author of each commit. This allows developers to get a clear picture of how the project has evolved and understand the decisions that were made along the way</li>
 <li style="">Debugging: When a bug is discovered in the code, Git logs can be used to track down the specific commit that introduced the bug. By examining the changes made in that commit, developers can gain insight into what caused the bug and how to fix it.</li>
 <li style="">Collaboration: When working on a project with multiple developers, Git logs can help keep everyone on the same page. By reviewing the logs, developers can see what changes have been made by others and understand the reasoning behind those changes. This can help ensure that everyone is working towards the same goals and prevent conflicting changes from being made.</li> 
</ol>
<h2 style="text-align: justify;">Git commit on the wrong branch </h2>
If you have made a Git commit on the wrong branch and the desired branch
 does not exist yet, this is the quickest way to correct your mistake. 
<pre style="text-align: justify;">git&nbsp;checkout -b&nbsp;new-branch git checkout -b wrong-branch git&nbsp;reset --hard&nbsp;HEAD~1 </pre> 
If your branch exists, you have two solutions. 
<pre style="text-align: justify;">#first solution git reset HEAD~1 --soft git stash git checkout -b correct-branch git stash pop git add . git commit -m "commit message" </pre>
<pre style="text-align: justify;">#second solution git checkout correct-branch git cherry-pick&nbsp;wrong-branch git checkout wrong-branch git reset --hard HEAD~1 </pre> 
<h2 style="text-align: justify;">Empty commit </h2>
A blank Git commit can be useful in several ways: 
<ol style="text-align: justify;">
 <li style="">Marking a specific moment in the code history: By creating a blank Git commit, you can mark a specific moment in the code history without changing the code content. This allows you to have a reference to a specific moment in history, which is useful in the later stages of project development.</li>
 <li style="">Triggering CI/CD workflows </li>
 <pre style="">git commit --allow empty -m 'run workflow!'</pre> 
</ol>
<h2 style="text-align: justify;">Git bisect </h2>
Git bisect tool is a command-line utility in Git that helps you find the specific commit that introduced a bug or regression by performing a binary search through the commit history. Here's an example of how to use the Git bisect tool: 

<ol style="text-align: justify;">
 <li style="">Identify a known good commit in the project history and a known bad commit where the bug is present.</li>
 <li style="">Start the bisect process by running git bisect start.</li>
 <li style="">Mark the known good commit as good by running git bisect good.
 </li>
 <li style="">Mark the known bad commit as bad by running git bisect bad<bad-commit>.</bad-commit>
 </li>
 <li style="">Git will checkout a commit between the good and bad commits for you to test.</li>
 <li style="">Test the current commit to see if the bug is present. If the current commit is good, run git bisect good. If the current commit is bad, run git bisect bad.</li>
 <li style="">Git will "checkout" another commit between the good and bad commits based on your response. Keep testing and marking commits until the bad commit is identified.</li>
 <li style="">End the bisect process by running git bisect reset.</li>
</ol>
By using the Git bisect tool, you can efficiently identify the specific commit that introduced a bug or regression in your codebase. Git is a very powerful tool when used correctly, and although some processes may seem difficult, once they become routine, all our Git problems will be forgotten. I hope this information has been helpful to you and see you on <a href="https://cyberlab.rs/blog" target="_blank">our blog</a> on the next topic!

If you're a software developer, chances are you're already familiar with GIT, the popular version control system used by teams all over the world. 