While working on Git, developers clone remote repositories so they can access the project’s files and make their changes. More specifically, cloning creates a local copy of a remote repository on the user’s local system and allows them to work on the project locally. After that, they can push their local changes back to the GitHub repository for other team members to access.
This write-up will explain:
- Is It Safe to Shallow Clone/Copy Git Repo With “–depth 1”, Make Commits, and Get/Pull Updates Again?
- How to Shallow Clone/Copy Git Repo With “–depth 1”, Make Commits, and Get/Pull Updates Again?
Is It Safe to Shallow Clone/Copy Git Repo With “–depth 1”, Make Commits, and Get/Pull Updates Again?
It is generally safe to shallow clone a repository with the “–depth 1” option, make commits and get/pull updates. However, this approach can lead to some minor issues, such as:
- Shallow cloning of a repository with “–depth 1” only clones or downloads the latest commits and not the entire history, so users cannot have access to the whole repository.
- Users cannot revert to an older version of the code.
- While pulling updates again, users will only be able to pull the changes made to the most recent commit. If there are changes to earlier commits that they need, they will not be able to get them.
- If developers create commits and push them to the repository, they will be based on the most recent cloned commit.
Overall, shallow cloning with –depth 1 can be useful for quickly getting a copy of the repository to work on, but it may not be the best option if you need to access the entire history of the code.
How do Shallow Clone/Copy Git Repo with “–depth 1”, Make Commits, and Get/Pull Updates Again?
To shallow clone a particular Git repository with depth 1, create commits and pull updates again, first, navigate to the local repository. Then, clone the remote repository with depth 1 using the “git clone –depth 1 <remote-URL>” command. Next, move to the cloned repository, make changes, and commit them. After that, perform push and pull operations.
Step 1: Switch to Local Repository
First, type out the following command and redirect to the desired local repository:
Step 2: Clone Remote Repository
Then, clone or copy the particular remote repository by utilizing the “git clone” command along with the desired depth and HTTP URL of the GitHub repository:
Here, the “–depth” option with a “1” value gets the latest commit only:
Step 3: Move to Remote Repository
Next, switch to the cloned repository through the “cd” command:
Step 4: Check Reference Log
Then, check the reference log to view the commits history:
It can be observed that the remote repository has been cloned with the latest commit only:
Step 5: Create a New File
Now, make a new file in the current cloned repository:
Step 6: Track File
Track the newly created file with the help of the “git add” command:
Step 7: Commit Changes
After that, execute the below-provided command to commit changes:
Step 8: Check Commits History
Then, check the reference log to verify the changes:
It can be seen that the new commit has been added to the commit history:
Step 9: Push Changes to GitHub
Run the below-listed command to push the new changes to the GitHub repository:
According to the below-provided image, the changes have been pushed to the remote Git repository:
Step 10: Pull Remote Changes
Now, get the remote updates to the cloned repository using the following command:
The below output shows that the repository is already up to date, which indicates that there are no new changes in the remote repository:
Now, suppose another user has made changes to the remote repository and you want to perform the pull operation, then you will only get the most recently applied changes:
It can be shown in the below-provided output, only the most recently added changes have been downloaded:
Step 11: Verify Changes
Lastly, execute the below-listed command to ensure that only recently applied changes are pulled into the locally cloned repository:
As you can see, the commit history only contains the latest changes:
That was all about shallow cloning a Git repository with depth 1, creating commits, and pulling updates again.
Conclusion
It is generally safe to shallow clone a repository with the “–depth 1” option, create commits, and pull updates. However, this approach can lead to issues if the repository’s history is modified to affect the commits users have made. Additionally, shallow cloning a repository with –depth 1 only download the latest commits and does not include the entire history of the repository. This means users cannot access the repository’s full context. This write-up explained shallow cloning a Git repository with depth 1, creating commits, and pulling updates again.
