It is fine when you and the rest of your team are working on different files. But sometimes, multiple people simultaneously work on the same files, and that's where the problems arise.
\nJust a Note: git pull = git fetch + git merge
In this scenario, when you have local changes in your system and you pull the latest contribution, you got this error.
\nerror: your local changes to the following files would be overwritten by merge: readme.md\nplease commit your changes or stash them before you merge.\nAborting...
git stash (stash the local changes clean the workspace)\ngit pull (pull the latest changes from remote )\ngit stash apply (apply the latest stash)
-----------(or)---------------
\ngit fetch (fetch the local machine folder)\ngit stash (stash the local changes clean the workspace)\ngit merge '@{u}' (merge the changes from local folder to workspace folder)\ngit stash pop (apply the latest stash )
By default, the stash changes will become staged. If you want to unstage them, use git restore --staged (git ver > 2.25.0).
git reset --hard HEAD (reset to the head means remove all local changes)\ngit pull (get the latest changes)
-----------(or)---------------
\ngit fetch (fetch the local machine folder)\ngit reset --hard HEAD (reset to the head means remove all local changes)\ngit merge '@{u}' (merge the changes from the local folder to workspace folder)
Now you must be thinking, what is git pull --force then?
it feels like it would help to overwrite local changes. instead, it fetches forcefully but does not merge forcefully (git pull --force = git fetch --force + git merge).
Like git push, git fetch allows us to specify which local and remote branch we want to work on. git fetch origin/ft-1:my-ft means the changes in the ft-1 branch from the remote repository will end up visible on the local branch my-ft. When such kind of operation modifies the existing history, it is not allowed by the Git without an explicit --force parameter.
Git cherry-pick is a powerful command that allows any specific Git commits to be selected by reference and append to the current working HEAD. The act of picking a commit from a branch and adding it to another is cherry picking. For undoing modifications, git cherry-pick can be useful. Say, for example, that a commit is made to the wrong branch unintentionally. You may turn to the right branch and select the commit to where it is supposed to belong.
To showcase this, let us assume we have a repository with the following branches:
\nalpha - beta - gama - delta `Master`\n \\\n x - neutron - Ultraviolet `Feature`git cherry-pick commitSha
In this example, commitSha is a reference to commit. Using the git log, you can locate a commit referenced assum we wanted to use commit 'neutron' in master in this example. We make sure that we are working on the master branch first.
\ngit checkout master
git cherry-pick neutron
Once executed, our Git history will look like:
\nalpha - beta - gama - delta - neutron `Master`\n \\\n x - neutron - Ultraviolet `Feature`\n\t The neutron commit has been successfully picked into the feature branch.
\ngit cherry-pick is a useful tool but isn't best practice always. Cherry-picking can trigger duplicate commits, and traditional merges are preferred instead in many situations where cherry-picking would work. Git cherry-pick is a useful option for a few situations.
\nA team will often find individual members working in or around the same code sometimes. Perhaps there is a backend and frontend component of a new product feature. There may be some shared code between two sectors of the product. Perhaps the developer of the backend produces a data structure that will also need to be used by the frontend. In order to select the commit in which this hypothetical data structure was created, the frontend developer could use git cherry-pick. This selection would allow the developer of the front end to continue progress on their project side.
\nWhen a bug is discovered, it is essential to fix that quickly as possible. For example, let's say a developer has started working on a new feature. During the development of a new feature, they find an existing bug. The developer creates an explicit commit to fix this bug. This new patch commit can be cherry-picked directly to the master branch to quickly fix the bug.
\nA feature branch can often go stale and not be merged into a master. Often, without merging, a pull request might be closed. Git never sacrifices those commits, and they can be identified and cherry-picked back to life by commands such as git log and git reflog.
\n-edit\nPassing the -edit option causes git to trigger a commit message before the cherry-pick process is introduced.
\n—no-commit\nThe —no-commit option executes the cherry-pick, but it transfers the contents of the target commit into the working directory of the current branch instead of making a new commit.
\n—the-signoff\nThe —signoff option adds the signature line 'signoff' to the end of the cherry-pick commit message at the end.
\nGit cherry-pick also accepts merge strategy options and conflict resolution as well. Please check the git merge strategy documentation.
\n","frontmatter":{"date":"November 17, 2020","updated_date":null,"title":"How to use Git Cherry Pick","tags":["git"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/7cc5358c073674d856e8ea5cddc47710/58556/cherrypck.webp","srcSet":"/static/7cc5358c073674d856e8ea5cddc47710/61e93/cherrypck.webp 200w,\n/static/7cc5358c073674d856e8ea5cddc47710/1f5c5/cherrypck.webp 400w,\n/static/7cc5358c073674d856e8ea5cddc47710/58556/cherrypck.webp 800w,\n/static/7cc5358c073674d856e8ea5cddc47710/99238/cherrypck.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Abhimanyu Singh Rathore","github":"abhir9","avatar":null}}}}]}},"pageContext":{"tag":"git"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}