As a noob in git, i have no idea how to have patch to current modified files relative to original ones, i.e. the first git clone. Anyone experienced expert on this developmental software versioning, mainly patch and diff for working as collaborator (in fork, PR, etc) so that explain the correct way ?

CodePudding user response：

Making a patch

You can create a patch that represents all your uncommitted changes simply by saving the output of git diff to a file:

git diff > my-changes.patch

This patch is just a file, and so you could email it to someone or save it on a thumb drive or do whatever else you wanted to with it (I'm not sure why you'd need to do this, but you can)

Then, the patch can be applied via

git apply my-changes.patch

You typically don't need to make patches manually, and when you do need to make patches, they should always be from pre-existing commits.

A patch can be made from pre-existing commits like so:

git diff <start commit>..HEAD > my-changes.patch

This will create a patch of all changes since <start commit>. You can also specify <start commit> as a branch, a tag (which refers to a specific commit), or something specific like main~10 (which would mean the main branch, 10 commits ago).

# Get a patch of all changes that haven't been pushed
git diff origin/main..main > local-changes.patch

# Get a patch of all changes on feature-branch
git diff main..feature-branch > changes-on-feature-branch.patch

# Get the last 10 commits as a patch
git diff main~10..main > last-10-commits.patch

# Get all the changes since a particular tag
git diff v1.0.0..main > changes-since-v1.0.0.patch

ONCE AGAIN, YOU TYPICALLY DO NOT NEED TO CREATE PATCHES MANUALLY!!! As a tool, git diff is really useful for exploring history, seeing current changes, seeing changes that will get merged, or a million other uses. It outputs stuff in a form that can be directly applied with git apply, but I haven't had to manually send someone a patch at any point in my entire life.

Collaborating in git, the right way

There are three typical ways to collaborate, which I'll list from easiest to most advanced.

Method 1: Multiple collaborators, who all have access

This is the most typical situation you'll see in school, or in most work environments. Everyone can push code to the same repository.

Once you have a copy of the repo on your machine, the workflow looks like this:

• Make changes or updates to the code

• Commit your changes: git add <your changes> && git commit

  You can make as many commits as you want before uploading. The best thing to do is make small commits every time you finish an important piece of code, like a function, or a class.

• Download remote changes: git pull

  If your partners or coworkers have updated the repository with changes, you have to do this before pushing. This allows you to check to make sure that your changes work with their changes.

• Upload your changes: git push

Method 2: you're working on someone else's open source project

You won't always be able to push your changes directly. For example, if you're working on an open source project, you'll typically submit changes for review, and the maintainers will be the ones to merge them.

This is typically done by forking the project, making changes, uploading your changes to your repository (the forked version), and then submitting a pull request to integrate your changes back into the original project.

It looks like this:

• Fork (on github, gitlab, or another service
• Clone the forked version onto your local machine
• Make changes
• Commit your changes
• Push your changes
• Create a pull request to merge your changes back in (You can do this on github, gitlab, or wherever you forked the repo)

Method 3: Email your commits as a patch

This method is typically used for larger, older open-source projects, that don't want to rely on a centralized service like github or gitlab.

It's done by using git send-email to email the patches directly from the command line. Git will create a patch for you automatically. All you have to do is specify the range of commits you want to send as a patch.

For example, if you made your changes on a local branch called dev, then you would use it like this:

git send-email --compose --from=<your email> --to=<their email> master..dev

Here, master..dev is the range of patches you're sending. It's all the patches on the dev branch, that aren't on the master branch. AKA, your changes.

This command will open a text editor where you can write the body of your email, and git will attach the patch to the email, and send it.

Note that you have to configure your email to work with git send-email. Beginners will not typically need to do this.