Sheldon  Grant

Sheldon Grant

1669884180

Learn My Favorite Git tools

Git reflog, git gc, git bisect, and git worktree are just a few of the tools I use routinely.

As with any other technology or skill, just reading about Git cannot make you proficient at it or make you an "advanced" user. Now it's time to dig into some of the tools in Git that I've found useful, and hopefully, that will help you use Git.

Git reflog

In my previous article, I wrote about Git history as a chain of commits, and that's a very good model for most purposes. However, Git actually remembers everything you do with Git, not just commits. You can see your entire recent history with git reflog.

Image of a Git reflog.

(Dwayne McDaniel, CC BY-SA 4.0)

The log that reflog refers to is found in .git/logs, and it's called HEAD. Opening this file, you can quickly see all the actions taken recently. Inside .git/logs/HEAD, you see rows corresponding to the output of the reflog command.

You can checkout any of the states in a reflog. No matter what you do, Git gives you a way to easily get your files back to a previous state!

To checkout a previous state, use the command:

git checkout HEAD@{<#>}

Replace <#> with the number of steps behind HEAD you want to reference. For instance, if I wanted to check out the state right before I did the last git pull from my example, I would use the command git checkout HEAD@{5} Doing this puts Git into a detached head state, so I would need to make a new branch from there if I wanted to preserve any changes I wanted to make.

By default, your reflog sticks around for at least 30 days before Git cleans up its history. But it does not throw this info away; it packs it into a more compressed form. You don't need to wait for Git to tidy up. You can do it any time with the garbage.

Git gc (garbage collection)

Even though the size of objects and files in your .git folders are tiny and highly compressed, when there are a lot of items present, then Git can start to slow down. After all, looking up entries from a list of 1,000 refs is more time-consuming than a list of only a handful of entries. From time to time, Git performs an internal garbage collection step, packing up all the objects and files not actively in use. It then stuffs them into a highly compressed pack file.

But you don't need to wait for Git to decide to clean up the unused objects. You can trigger this any time you want with the git gc command.

Image of Git garbage collection before and after.

(Dwayne McDaniel, CC BY-SA 4.0)

Next time you've made hundreds of commits locally, or you just notice that Git commits are taking a little longer than usual, try running git gc. It might speed things up.

Git bisect

The git bisect command is a powerful tool that quickly checks out a commit halfway between a known good state and a known bad state and then asks you to identify the commit as either good or bad. Then it repeats until you find the exact commit where the code in question was first introduced.

Git worktree

Imagine a scenario where you are working in a branch, very deep into adding new dependencies, and are not in any way ready to make a commit. Suddenly, your pager goes off. There's a fire is happening in production, and you need to drop everything, switch to a hotfix branch, and get that patch built quickly.

It's decision time. Do you could cross your fingers, make a commit, and hope you remember where you left off? Do you git stash, which might cause dependency issues and also mean you have to remember what exactly you were doing when you stashed? Or do you just checkout the other branch with a different folder and work as you usually would?

That last option might sound too good to be true, but that is precisely what Git worktree allows you to do.

Normally with Git, you can only have one branch checked out at a time. This makes sense, now that you know that Git tracks the active branch with HEAD, which can only reference one ref at a time.

Git worktree sidesteps this limitation by making copies of branches outside the repository folder. Git knows that this other folder exists and that any commits made there need to be accounted for in the original repo folder. But the copy of the branch also has its own HEAD file keeping track of where Git is pointing in that other location!

Image of git tree copying branches.

(Dwayne McDaniel, CC BY-SA 4.0)

Git always has at least one worktree open, which you can see by running the command:

git worktree list

This command shows you the current folder where .git is located, the most recent commit ID, and the name of the currently checked out branch at the end of the line.

You can add more entries to the worktree list with the command:

git worktree add /path-to-new-folder/<branch-name>

The add directive creates a new folder at the specified path, named the same as the target branch. Git also sends a linked copy of the repo to that folder, with that branch already checked out. To work in that branch, all you need to do is change the directory then proceed to work as usual.

When you are ready to go back to the original work you were focused on before being interrupted, just change directly back to the original folder. Your work is in the exact same state you left it earlier.

When you are done and want to clean up after yourself, remove any worktree items you want with the command git worktree remove /path-to-new-folder/<branch-name>

A few words of warning for using Git worktree:

If a branch is assigned to a worktree, you can not check it out as you normally would. Attempting to checkout a branch that is already checked out throws an error.

It's a good idea to remove any unneeded worktree entries as soon as you're finished with them. Errors might occur when running other Git operations while multiple branches are checked out.

When working in a code editor like VS Code, changing directory in the terminal doesn't automatically change the open folder in your editor. Remember to open the desired folder through the file menu to ensure you are modifying the correct version of the project files.

So much more to Git

While it might feel like I've covered a lot here, I've actually only scratched the surface of what's possible with Git. It's possible to build entire applications that complement Git, and extending that even further is possible. Fortunately, there are also a lot of resources you can turn to when learning Git.

The one book I would recommend everyone read is absolutely free and you can download it right now. The Pro Git Book covers how Git works in great detail and gives a lot of excellent examples. The one caveat about the book, though, is that it is a little out of date. The free version linked from the git-scm website is from 2014. Still, this book gives you the best foundational knowledge of how Git works and helps make any other Git-related topics more accessible.

There are also cheat sheets and articles out there to help you become a Git expert in no time. But as I said earlier in this article, the only way to learn Git, or any other skill, is to practice, practice, practice.

Original article source at: https://opensource.com/

#git #tool 

What is GEEK

Buddha Community

Learn My Favorite Git tools
Madyson  Reilly

Madyson Reilly

1604109000

Best Practices for Using Git

Git has become ubiquitous as the preferred version control system (VCS) used by developers. Using Git adds immense value especially for engineering teams where several developers work together since it becomes critical to have a system of integrating everyone’s code reliably.

But with every powerful tool, especially one that involves collaboration with others, it is better to establish conventions to follow lest we shoot ourselves in the foot.

At DeepSource, we’ve put together some guiding principles for our own team that make working with a VCS like Git easier. Here are 5 simple rules you can follow:

1. Make Clean, Single-Purpose Commits

Oftentimes programmers working on something get sidetracked into doing too many things when working on one particular thing — like when you are trying to fix one particular bug and you spot another one, and you can’t resist the urge to fix that as well. And another one. Soon, it snowballs and you end up with so many changes all going together in one commit.

This is problematic, and it is better to keep commits as small and focused as possible for many reasons, including:

  • It makes it easier for other people in the team to look at your change, making code reviews more efficient.
  • If the commit has to be rolled back completely, it’s far easier to do so.
  • It’s straightforward to track these changes with your ticketing system.

Additionally, it helps you mentally parse changes you’ve made using git log.

#open source #git #git basics #git tools #git best practices #git tutorials #git commit

7 Best Practices in GIT for Your Code Quality

There is no doubt that Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Still, developers struggle for code quality. Why? They fail to follow git best practices. In this post, I will explain seven core best practices of Git and a Bonus Section.

1. Atomic Commit

Committing something to Git means that you have changed your code and want to save these changes as a new trusted version.

Version control systems will not limit you in how you commit your code.

  • You can commit 1000 changes in one single commit.
  • Commit all the dll and other dependencies
  • Or you can check in broken code to your repository.

But is it good? Not quite.

Because you are compromising code quality, and it will take more time to review codeSo overall, team productivity will be reduced. The best practice is to make an atomic commit.

When you do an atomic commit, you’re committing only one change. It might be across multiple files, but it’s one single change.

2. Clarity About What You Can (& Can’t) Commit

Many developers make some changes, then commit, then push. And I have seen many repositories with unwanted files like dll, pdf, etc.

You can ask two questions to yourself, before check-in your code into the repository

  1. Are you suppose to check-in all these files?
  2. Are they part of your source code?

You can simply use the .gitignore file to avoid unwanted files in the repository. If you are working on more then one repo, it’s easy to use a global .gitignore file (without adding or pushing). And .gitignore file adds clarity and helps you to keep your code clean. What you can commit, and it will automatically ignore the unwanted files like autogenerated files like .dll and .class, etc.

#git basics #git command #git ignore #git best practices #git tutorial for beginners #git tutorials

Sheldon  Grant

Sheldon Grant

1669884180

Learn My Favorite Git tools

Git reflog, git gc, git bisect, and git worktree are just a few of the tools I use routinely.

As with any other technology or skill, just reading about Git cannot make you proficient at it or make you an "advanced" user. Now it's time to dig into some of the tools in Git that I've found useful, and hopefully, that will help you use Git.

Git reflog

In my previous article, I wrote about Git history as a chain of commits, and that's a very good model for most purposes. However, Git actually remembers everything you do with Git, not just commits. You can see your entire recent history with git reflog.

Image of a Git reflog.

(Dwayne McDaniel, CC BY-SA 4.0)

The log that reflog refers to is found in .git/logs, and it's called HEAD. Opening this file, you can quickly see all the actions taken recently. Inside .git/logs/HEAD, you see rows corresponding to the output of the reflog command.

You can checkout any of the states in a reflog. No matter what you do, Git gives you a way to easily get your files back to a previous state!

To checkout a previous state, use the command:

git checkout HEAD@{<#>}

Replace <#> with the number of steps behind HEAD you want to reference. For instance, if I wanted to check out the state right before I did the last git pull from my example, I would use the command git checkout HEAD@{5} Doing this puts Git into a detached head state, so I would need to make a new branch from there if I wanted to preserve any changes I wanted to make.

By default, your reflog sticks around for at least 30 days before Git cleans up its history. But it does not throw this info away; it packs it into a more compressed form. You don't need to wait for Git to tidy up. You can do it any time with the garbage.

Git gc (garbage collection)

Even though the size of objects and files in your .git folders are tiny and highly compressed, when there are a lot of items present, then Git can start to slow down. After all, looking up entries from a list of 1,000 refs is more time-consuming than a list of only a handful of entries. From time to time, Git performs an internal garbage collection step, packing up all the objects and files not actively in use. It then stuffs them into a highly compressed pack file.

But you don't need to wait for Git to decide to clean up the unused objects. You can trigger this any time you want with the git gc command.

Image of Git garbage collection before and after.

(Dwayne McDaniel, CC BY-SA 4.0)

Next time you've made hundreds of commits locally, or you just notice that Git commits are taking a little longer than usual, try running git gc. It might speed things up.

Git bisect

The git bisect command is a powerful tool that quickly checks out a commit halfway between a known good state and a known bad state and then asks you to identify the commit as either good or bad. Then it repeats until you find the exact commit where the code in question was first introduced.

Git worktree

Imagine a scenario where you are working in a branch, very deep into adding new dependencies, and are not in any way ready to make a commit. Suddenly, your pager goes off. There's a fire is happening in production, and you need to drop everything, switch to a hotfix branch, and get that patch built quickly.

It's decision time. Do you could cross your fingers, make a commit, and hope you remember where you left off? Do you git stash, which might cause dependency issues and also mean you have to remember what exactly you were doing when you stashed? Or do you just checkout the other branch with a different folder and work as you usually would?

That last option might sound too good to be true, but that is precisely what Git worktree allows you to do.

Normally with Git, you can only have one branch checked out at a time. This makes sense, now that you know that Git tracks the active branch with HEAD, which can only reference one ref at a time.

Git worktree sidesteps this limitation by making copies of branches outside the repository folder. Git knows that this other folder exists and that any commits made there need to be accounted for in the original repo folder. But the copy of the branch also has its own HEAD file keeping track of where Git is pointing in that other location!

Image of git tree copying branches.

(Dwayne McDaniel, CC BY-SA 4.0)

Git always has at least one worktree open, which you can see by running the command:

git worktree list

This command shows you the current folder where .git is located, the most recent commit ID, and the name of the currently checked out branch at the end of the line.

You can add more entries to the worktree list with the command:

git worktree add /path-to-new-folder/<branch-name>

The add directive creates a new folder at the specified path, named the same as the target branch. Git also sends a linked copy of the repo to that folder, with that branch already checked out. To work in that branch, all you need to do is change the directory then proceed to work as usual.

When you are ready to go back to the original work you were focused on before being interrupted, just change directly back to the original folder. Your work is in the exact same state you left it earlier.

When you are done and want to clean up after yourself, remove any worktree items you want with the command git worktree remove /path-to-new-folder/<branch-name>

A few words of warning for using Git worktree:

If a branch is assigned to a worktree, you can not check it out as you normally would. Attempting to checkout a branch that is already checked out throws an error.

It's a good idea to remove any unneeded worktree entries as soon as you're finished with them. Errors might occur when running other Git operations while multiple branches are checked out.

When working in a code editor like VS Code, changing directory in the terminal doesn't automatically change the open folder in your editor. Remember to open the desired folder through the file menu to ensure you are modifying the correct version of the project files.

So much more to Git

While it might feel like I've covered a lot here, I've actually only scratched the surface of what's possible with Git. It's possible to build entire applications that complement Git, and extending that even further is possible. Fortunately, there are also a lot of resources you can turn to when learning Git.

The one book I would recommend everyone read is absolutely free and you can download it right now. The Pro Git Book covers how Git works in great detail and gives a lot of excellent examples. The one caveat about the book, though, is that it is a little out of date. The free version linked from the git-scm website is from 2014. Still, this book gives you the best foundational knowledge of how Git works and helps make any other Git-related topics more accessible.

There are also cheat sheets and articles out there to help you become a Git expert in no time. But as I said earlier in this article, the only way to learn Git, or any other skill, is to practice, practice, practice.

Original article source at: https://opensource.com/

#git #tool 

Jerad  Bailey

Jerad Bailey

1598891580

Google Reveals "What is being Transferred” in Transfer Learning

Recently, researchers from Google proposed the solution of a very fundamental question in the machine learning community — What is being transferred in Transfer Learning? They explained various tools and analyses to address the fundamental question.

The ability to transfer the domain knowledge of one machine in which it is trained on to another where the data is usually scarce is one of the desired capabilities for machines. Researchers around the globe have been using transfer learning in various deep learning applications, including object detection, image classification, medical imaging tasks, among others.

#developers corner #learn transfer learning #machine learning #transfer learning #transfer learning methods #transfer learning resources

30+ Tools List for GitOps

GitOps—which takes automation facets of the DevOps methodology—is an approach that aims to streamline infrastructure management and cloud operations with software development and deployment. While many consider GitOps a replacement for DevOps, it is not—the approach simply concentrates on the means of automating one facet of the DevOps methodology.

Specifically, GitOps uses Git pull requests to automate infrastructure provisioning and software deployment, all for the purpose of making CI/CD a more efficient process.

GitOps uses Git as a single source of truth for both application development and cloud infrastructure; declarative statements are used for streamlining configuration and deployment.

GitOps unifies a number of key tasks such as deployment, management, and monitoring of cloud clusters (specifically containers running in the cloud) and allows for developers to have more control over their application deployment pipeline. Since Git works for Infrastructure as Code (IaC) as well as application development, it is an ideal repository of truth for the approach.

Benefits of GitOps

GitOps offers some key advantages to those who employ the approach, starting with the more refined CI/CD pipeline itself. The approach fully leverages the benefits of cloud-native applications and scalable cloud infrastructure without the usual complications. Other benefits include:

  • Higher reliability, made possible by Git’s native features. You can roll-back deployments and use Git’s tracking mechanism to revert to any version of the app should new codes cause errors. This results in a more robust cloud infrastructure too.
  • Improved stability, particularly when it comes to managing Kubernetes clusters. Everything is traceable and changes in cluster configuration can also be reverted if needed. An audit log is automatically created with Git as the source of truth.
  • Better productivity, allowing developers to focus more on the quality of their codes rather than the pipeline itself. Everything is fully automated once new codes are committed to Git, plus there are additional automation tools to utilize.
  • Maximum consistency, especially with the entire process being managed using the same approach from end to end. GitOps simplifies everything from apps, Kubernetes add-ons, and the Kubernetes infrastructure as a whole.

Many perspectives believe that GitOps offers the best of both worlds, combining continuous delivery with cloud-native advantages and IaC. GitOps best practices also make the end-to-end pipeline standardized, and you can integrate the approach with any existing pipeline without making big changes. You just need the right tools for the job.

#git #gitops #git basics #git tools #git best practices