Step 1: Clone the source repository and make sure you have the latest code

The first step is to clone the repository that contains the code you want to move. For example, let's say you want to move some code from repo1 to repo2. You can clone repo1 using the following command:

git clone https://github.com/user/repo1.git

Then, you can change to the directory of repo1 and make sure you have the latest code by pulling from the remote branch. For example, if you want to move code from the master branch, you can do:

cd repo1
git pull origin master

Step 2: Create a patch file using git show command

The next step is to create a patch file that contains the changes you want to move. A patch file is a text file that shows the differences between two versions of code, using the unified diff format. You can create a patch file using the git show command, which shows the changes introduced by a specific commit. For example, if you want to move the code from the commit with the hash 123456, you can do:

git show 123456 > mypatch.patch

This will create a file named mypatch.patch in the current directory, which contains the changes from the commit 123456. You can also use other options with the git show command, such as --stat to show the statistics of the changes, or --name-only to show only the names of the files changed. You can also create a patch file from multiple commits, using the git format-patch command. For more details, check out the git documentation.

Step 3: Clone the destination repository and create a new branch

The third step is to clone the repository where you want to move the code. For example, you can clone repo2 using the following command:

git clone https://github.com/user/repo2.git

Then, you can change to the directory of repo2 and create a new branch where you will apply the patch. It is a good practice to create a new branch for applying patches, so that you can easily revert or modify the changes if needed. For example, you can create a new branch named patch-branch using the following command:

cd repo2
git checkout -b patch-branch

Step 4: Apply the patch

The final step is to apply the patch file to the destination repository. You can do this using the git apply command, which applies a patch to the current working directory. For example, you can apply the patch file mypatch.patch that you created in step 2 using the following command:

git apply mypatch.patch

However, this command may fail if there are conflicts or differences between the source and destination repositories. For example, the patch may try to modify a file that does not exist, or a line that has been changed in the destination repository. In this case, you can use the --reject parameter, which allows you to apply the patch partially, and handle the parts that do not apply manually. For example, you can do:

git apply --reject mypatch.patch

This will apply the patch as much as possible, and create a .rej file for each file that has conflicts or differences. The .rej file contains the parts of the patch that did not apply, and you can review them using a text editor or a code editor. For example, using VS Code gives you a better view that colors the code for added/removed code green/red. You can then edit the files and resolve the conflicts or differences, and delete the .rej files when you are done.

Step 5: Commit and push the changes to the destination repository

Once you have applied the patch and resolved any conflicts or differences, you can commit and push the changes to the destination repository. For example, you can do:

git add .
git commit -m "Applied patch from repo1"
git push origin patch-branch

This will commit and push the changes to the branch patch-branch in the remote repository. You can then create a pull request to merge the changes to the main branch, or any other branch you want. This method does not care particularly about the history from the previous repository, and it will be wiped away when a new pull request is created in the new repository.

Conclusion

In this post, I showed you how to move code from one repository to another using git patch, a handy feature that allows you to create and apply patch files that contain the differences between two versions of code. This can be useful when you want to reuse some code snippets, refactor your codebase, or migrate to a new repository. I hope you found this post helpful and learned something new. If you have any questions or feedback, feel free to leave a comment below. Happy coding! 😊

What is DNS?

The Domain Name System (DNS) is analogous to a phonebook for the Internet. It lists domain names with their corresponding IP addresses (DNS Record).

Why do we need DNS?

It would be extremely tedious to remember and enter IP addresses for our favorite websites. Domain names were born to solve this problem by using letters rather than numbers allowing users to select easy to remember domain names for their websites. DNS is used to translates these domain names to IP addresses and eliminates the need for us to memorize any IP addresses.

How does DNS work?

1. The domain ‘joelcolaco.com’ is typed into a web browser and a DNS query is sent to the DNS resolver.

2. The resolver queries a DNS root nameserver.

3. The root nameserver responds to the resolver with the address of a Top Level Domain (TLD) DNS server. (In this example the .com TLD)

4. The resolver makes a request to the .com TLD DNS server.

5. The TLD DNS server responds with the IP address of the domain’s nameserver.

6. The resolver sends a query to the Authoritative name server (domain’s nameserver). This is where if a zone file exists with a:

   • CNAME - a subdomain/domain can be pointed to another domain name which is returned to the resolver
   • A Record - a domain is mapped to an IP which is returned to the resolver

7. If a domain name is returned we restart the process with the new domain provided to the resolver. If an IP address is returned it is provided to the resolver from the authoritative nameserver.

8. The DNS resolver responds to the browser with the IP address of the domain requested.

9. The browser makes a HTTP request to the IP address.

10. The server at that IP returns the webpage to be displayed in the browser.

Common DNS Record Types

• A: Map a domain name to IPv4 addresses
• AAAA: Map a domain name to IPv6 addresses
• CNAME: Canonical Name (CNAME) Record is used in the Domain Name System (DNS) to map one domain name to another domain name.
• PTR: Resolve IPv4 or IPv6 addresses to domain names
• NS: Provides a list of the authoritative name servers responsible for the domain
• MX: Provides the domain names of mail servers that receive emails on behalf of a domain
• SOA: Provides details about a DNS zone; required for every DNS zone
• TXT: Provides arbitrary information to be shared in text format