![]() You apply a patch with the patch command: $ patch a prime.patch Once I have a patch file containing all of my changes, I can send it to you to review and, optionally, apply to your old file. The contents of the file are exactly the same as what was output to the terminal. You can do this using standard Bash redirection: $ git diff a > prime.patch The git diff command output is a valid patch file, in addition to being informative to the Git repo owner. A minus sign ( -) at the beginning of a line indicates a line that was removed or changed. A plus sign ( +) at the beginning of a line indicates something added to the old file. This is the same view as the one provided by the diff command using the -unified option, and it's also the correct syntax to use with the patch command. When you change a committed file in Git, you can see the changes you've made using git diff: $ git diff a The git diff and patch commands solve this problem. However, with larger files, updating the original file to match the new one would be difficult and prone to mistakes. The if statement was updated, and a bunch of code was added at the end. With a small file such as this, it's relatively trivial to see what's changed. ![]() I change some of your existing code, and I add some of my own: function prime(num) So you send the file to me, and I save it as prime_a and make some changes to it. It's valid code, it works as expected, but it's incomplete. So far, the file a contains: function prime(num) You don't actually need to know Lua for this example to be relevant. I'll use an example written in Lua because it's easy to read. Suppose you and I are collaborating on a project to calculate prime numbers. With the git diff command, you can create a record of how the file has changed, and the owner of a repository can use the patch command to "replay" those changes over the old version to bring it up to date with the new version. These are the tools everyone used before online Git hosts moved the process into the browser, and they're just as valid today as ever. But what do you do when you're not using a Git platform-as-a-service (PaaS) provider or when you want a streamlined process for submitting changes? To make this process seamless, many online Git repository providers have adopted the "merge request" or "pull request" model, in which they expect contributors to clone (often called "fork," even though the intent is actually not to fork the project) the entire repository and then submit a request through the online platform to integrate the changed branch back into the original repo. Cheat sheet: Old Linux commands and their modern replacements.Linux system administration skills assessment.A guide to installing applications on Linux.Download RHEL 9 at no charge through the Red Hat Developer program.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |