How to revert to previous packages if Laravel’s “composer update” breaks site?

When you run composer update and some packages break after the update, you can revert your project to the previous working state. Here’s how to handle it:

1. Check composer.lock file

After running composer update, the composer.lock file gets updated with the new versions of your dependencies. If things break, you can use Git to revert to the previous composer.lock.

2. Revert composer.lock using Git

If you are using Git and you committed the composer.lock file before running the update, you can easily go back to the previous version of the file. Here’s how:

git checkout HEAD^ composer.lock

This command checks out the previous version of the composer.lock file (the version before the last commit). If you want to revert to a specific commit, use the commit hash instead:

git checkout <commit-hash> composer.lock

3. Reinstall the previous dependencies

After reverting the composer.lock file, you need to install the previous versions of the packages defined in the restored composer.lock:

composer install

Note: Do not use composer update, as this will update the packages again. composer install will install the versions defined in composer.lock.

4. Commit the reverted composer.lock (if necessary)

After confirming that everything works as expected, commit the reverted composer.lock file:

git add composer.lock
git commit -m "Revert composer.lock to previous working state"

5. Lock Specific Package Versions (Optional)

If you want to prevent certain packages from being updated in the future, you can specify the exact versions in composer.json by using the caret (^) or tilde (~) version constraints. For example:

{
   "require": {
       "package/name": "^1.0"
   }
}

This ensures that composer update won’t update beyond the specified version.

By following these steps, you can safely revert your Composer dependencies back to a working state after an update causes issues.

Can you copy SSH keys to new PC? (Windows or Linux)

You dont need to generate new SSH keys when switching or upgrading to new PC.

Copying SSH Keys to a New PC: Windows and Linux

On Linux:

  1. Locate Your SSH Keys: Your keys are usually in the ~/.ssh/ directory.
    ls -al ~/.ssh
  2. Copy the Keys: Use a USB drive or a secure transfer method. If using scp:
    scp -r ~/.ssh username@newPC_IP:~/
  3. Set Permissions: On the new PC, set the correct permissions:
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/id_rsa
    chmod 644 ~/.ssh/id_rsa.pub
  4. Test the Connection:
    ssh -T git@github.com

On Windows:

  1. Locate Your SSH Keys: If using Git Bash, your keys are typically in C:\Users\YourUsername\.ssh\.
  2. Copy the Keys: You can copy the .ssh folder to a USB drive or use file transfer methods.
  3. Paste to the New PC: On the new PC, paste the .ssh folder into C:\Users\YourUsername\.
  4. Permissions: You do not need to set permissions on Windows. Just ensure your private key (id_rsa) remains secure.
  5. Test the Connection:
    ssh -T git@github.com

Notes:

  • Ensure Security: Keep your private key secure and do not share it.
  • SSH Agent: If you use an SSH agent, you may need to add your key again on the new PC with ssh-add.
  • Update Public Key: If necessary, copy the contents of id_rsa.pub and update it in your Git service account settings.

What is the difference between ‘git push – set-usptream origin ‘ and ‘git push’

Difference Between git push --set-upstream origin and git push

The difference between git push --set-upstream origin <branch> and git push lies in how they handle the relationship between your local branch and the remote branch.

1. git push --set-upstream origin <branch>

  • Purpose: This command pushes your local branch to the remote repository and establishes a tracking relationship between the local branch and the remote branch.
  • Upstream Tracking: It sets the upstream branch for the current local branch. After this, future git push and git pull commands can be used without specifying the remote or branch name.
  • Example:
    git push --set-upstream origin feature-branch

    This pushes the feature-branch to the origin remote and sets it as the upstream branch for the current local branch.

  • Use case: If you’re pushing a branch to the remote for the first time or if the local branch does not yet have an upstream branch set, this command ensures that future pushes/pulls can be done with fewer commands.

2. git push

  • Purpose: This command pushes your current branch to the remote repository, but only if an upstream branch is already set.
  • No Upstream Tracking: If the current branch doesn’t have an upstream (tracking) branch set, Git will return an error and ask you to specify where to push.
  • Example:
    git push

    If you’re on feature-branch and an upstream branch is already set (e.g., from a previous --set-upstream command), it pushes to the appropriate remote and branch.

  • Use case: Use this when the upstream branch is already set, and you just want to push your changes without specifying details.

So, in short:

  • git push --set-upstream origin <branch>: Pushes the branch and sets up a connection between your local and remote branch for future operations.
  • git push: Pushes to the remote branch, but only if the upstream branch is already set.