When I need to save my changes from one branch before checking out to another branch, git sometimes says: stage or commit the files before you can checkout to another branch. But I have been recommended to use stash option so:
Stage the files is not enough to save my files before checking out to another branch?
What are the differences between stage and stash files?
Thanks
1.- More than "save" your files, is act as Git expect to according their flow. (Advice, Git knows :) )
2.- Stash will move your modified files into a stack. So, later in the same or in another branch, you will be able to bring them back and see those modifications in your project.
Stage is the step before to make a commit, you add modified files to "Staged files" to create your next commit.
Now, you stash your files with
$git stash
and you add files (stage) with
$git add
Now, why is better stash your changes than staging them?
Maybe this part of the documentation can solve your doubts:
From documentation:
Stashing:
Often, when you’ve been working on part of your project, things are in
a messy state and you want to switch branches for a bit to work on
something else. The problem is, you don’t want to do a commit of
half-done work just so you can get back to this point later. The
answer to this issue is the git stash command.
See the links below :
Git Stashing Doc
Git Add Doc
Staging example
Git Basics
It's better to ask difference between stash vs commit and not stash vs stage.
You can not checkout to another branch before commit or stash current changes.
Therefore, if you want to not commit your changes, and also want to checkout to another branch, solution is to stash current changes, checkout to another branch. And after returning to first branch, you can apply stashed changes.
Related
I committed like 10 individual cherry-picked changes to my new release branch, and now after regression testing found that one of those commits in the middle may have broken something. I am prepared to release a new version of the code but exclude that commit. Must I start over cherry-picking into the new release branch to do this right, or is there a way I can simply copy my current branch into a new release branch and revert or undo the single offending commit without losing those that came before or after it?
I ended up creating a new release branch and starting over, cherry-picking into the new release branch the individual commits that I wanted and skipping the one I didn't want.
There is also another method I learned but didn't use--which is,
git revert <commit-hash>
However, while it does undo a commit in the branch where it exists so that the resulting code is devoid of that commit's changes, git revert does create a new revert-related commit in the git log for that branch to undo the unwanted commit--so it's not really a clean, make-like-it-never-happened erasure because you'll still see it in the branch's history.
I got conflicts When I try to rebase feature_branch with develop in android studio. When I resolve those conflicts again another set of files comes up with conflicts. This is happening because feature_branch has many commits.
Can someone suggest to rebase feature_branch to develop in this case?
Git accomplishes rebase by creating new commits and applying them to the specified base. The branch is composed of entirely new commits.
You can minimize the new commits by running git rebase with the -i flag. Instead of blindly moving all of the commits to the new base, interactive rebasing gives you the opportunity to alter individual commits in the process. This lets you clean up history by removing, splitting, and altering an existing series of a commit.
https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
First step to do before rebasing is to squash all commits to one final new commit. you can do this using git rebase -i HEAD~N where N is the number of commits you have in the current branch.
After this, you can easily rebase with a develop branch with easy conflicts.
This method may lose the commit history of the current branch as we are squashing all commits to one. If you want to save the history of the current branch then create new branch from the current branch before doing rebase as mentioned in the first point.
I have pushed a commit by mistake to my Gitlab. How can I undo it?
Easy way is to click the revert button in the merged merge request.
Click for Reference docs
Steps to revert a merge request from UI:
Click revert button
This creates a new branch rever-some_sha.2
Either opt for a new merge request and submit that.
[ Or ]
Checkout to revert-some_sha locally, add any changes you wanted.
Create a merge request and click merge to master.
Recommendation: Do a periodical rebase of your branch to be on top of master. Which avoids any conflicts and helps to catch any failing tests before even merging your branch.
I quote rednaw:
You can revert commits with git revert . This will create
a new commit which reverts the changes of the commit you specified
with the .
Note that you only revert that specific commit, and not commits after
that. If you want to revert a range of commits, you can do it like
this:
git revert <oldest_commit_hash>..<latest_commit_hash>
Just note that this command is a little bit funny. It actually doesn't
revert the commit specified with itself, but the
commits after that until and including .
Look at the git-revert man page for more information about the git
revert command. Also look at this answer for more information about
reverting commits.
Note that this revert command also deletes the corresponding local
files
Assuming that you mistakenly created a merge request on Gitlab,
All you have to do is scroll to the bottom of the merge request page and click on the
button close merge request
I have seven commits I need to add change IDs to. I see a lot of people say to use interactive git rebase. I'm not familiar with rebasing, and I'm having trouble with the files and functions that I changed the name of reverting back when I try and reword them to add change IDs.
Is there any other way to add change IDs? Or how do I stop my files/functions reverting back when I try and rebase. Once I abort the rebase, they go back to how I had them.
Thanks!
Try the following, and note you will need to
push and [Submit] one commit at a time:
Set the Gerrit Hook to add the Change-ID as you commit (or amend)
Create a new branch for your changes
For each of the changes, starting with the OLDEST, do:
git cherry-pick ...
git commit --amend (this should add a Change-ID - different one each time)
(push the change to Gerrit - however you do that)
In Gerrit - approve and [Submit] this change
In your branch, again, do git pull --rebase
First, sorry for such a confusing pesky title, I really can't find a better way to describe this (would appreciate any changes suggested to post).
The problem
I synced a github repo. And also modified some files and codes inside according to my needs. But if I want to resync and update my tree to latest commits.
will my changes be overwritten?
Or will repo simply ignore modified files and move on to other files?
Or will there be patching process (I dont think this would be case since chances of problems with auto-patching are quite high)?
My guess is that it skips over modified files. And I may need to manually get the new commits from repo. But how to determine which files that have been modified have new commits? I just want to determine it, then probably manually fetch and modify them manually.
To clarify:
Consider files named "abc" and "def" which I modified.
The repo owner updated his repo with a lot of new commits.
I ran repo sync and it synced all files to newer commits except those I modified. Now how do I determine if the files that repo owner updated include "abc" and/or "def" too (assuming I myself modified a lot of files, so I can't manually check if each file has new commit or not)?
I don't want to see what files I have modified or a complete list of files with new commits, I just want to see if the files that I modified have new commits or not.
Is there any such possible way?
I do know how to determine files that are changed using `git status,
but how do I want to check if those changed files have any new commits.
When running repo sync, Repo will rebase any non-published topic branches (i.e. branches you haven't uploaded to Gerrit with repo upload).
Or will there be patching process (I dont think this would be case since chances of problems with auto-patching are quite high)?
Git will try, but if there's a conflict that it can't resolve by itself you have to step in and help out.
Consider files named "abc" and "def" which I modified. The repo owner updated his repo with a lot of new commits. I ran repo sync and it synced all files to newer commits except those I modified.
No. Either Repo rebases your branch (and updates/merges all files) or it doesn't do anything and it's up to you need to rebase or merge from the upstream. Git never does partial updates.
I dont want to see what files I have modified or a complete list of files with new commits, I just want to see if the files that I modified have new commits or not.
I think you're asking the wrong question, but sure, you can list the commits that modify a particular set of files or compare two commits and only display the differences in a particular set of files. Both git diff and git log accept one or more paths to files that you want to restrict the output to. To find the files you can use git ls-files -mo to obtain dirty files and untracked files in your workspace, git diff-tree --name-only -r HEAD~..HEAD to get the files modified by the most recent commit, and so on.
Putting it all together, the following command fetches the most recent state from the upstream and shows the new commits (git log HEAD..origin/master) that touch upon files that you yourself have modified on the current branch since the last update from the upstream (git diff-tree --name-only -r origin/master..HEAD):
git fetch
git log HEAD..origin/master -- $(git diff-tree --name-only -r origin/master..HEAD)
A Unix-like shell is assumed. On Windows things may look differently.
You can use git hook to track the list of files.
In your post-receive hook search for the given file and do what ever you need to do.
Another option is to track it manually using the follow flag
git log --follow <path>, it will print out the list of changes made to the given file in each commit