after doing a git checkout HEAD~2 right after commit, the untracked files that I commited are gone in the local repository, since checkout does return the working dir to previous commit, but how can I recover those files or the "new changes" made to my local working directory without performing the latest commit. The latest commit wasn't pushed. The other user's commits on the repo became staged since the head was detached to the latest commit.
Related
There are two accounts in linux server, root and super.
I can git pull to latest code by root account
I cannot git pull to latest code by super account
I found the status content is different by execute git status
super#api-dev:~/dnmp/www/localhost$ git status
On branch develop
Your branch is up to date with 'origin/develop'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
../../data/
../../docker-compose.yml
../../services/
../
nothing added to commit but untracked files present (use "git add" to track)
...
root#api-dev:~/dnmp/www/localhost# git status
On branch develop
Your branch is up to date with 'origin/develop'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: composer.lock
no changes added to commit (use "git add" and/or "git commit -a")
There is a git repository root in ~/dnmp/
There is another git repository root in ~/dnmp/www/localhost
I want to change git status of super account to the same as root content.
Any idea to fix the difference?
git is different from other source control systems. When you clone a repository, it creates a local repository copy on your computer. So you have 1 copy as root, and another copy as super.
Then you can modify the files in your local copy, even commit these changes. But the main repository will not know of these until you push them into it.
So, when you run git status it shows you the state of the local repository, not the state of the main git repository.
To sync your local repositories with the main one, you can:
delete your local repository and clone from scratch.
pull the files from the main repository with git pull.
If you want to keep some changes you made locally, you will have to commit and push these up to the main repository first.
You can read on git, like this simple page: https://rogerdudler.github.io/git-guide/
More in depth sites exist to explain the whole of git, like:
https://www.atlassian.com/git/tutorials
https://www.freecodecamp.org/news/what-is-git-and-how-to-use-it-c341b049ae61/
I pushed latest codes from my GitLab repository. The changes was coming from my local development machine. I've successfully done it using this commands:
git push
to push my latest changes to my GitLab repository. Now I pulled the updates on server but unfortunately it did not happen successfully since I have uncommitted changes from the server.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: .htaccess
modified: composer.json
modified: composer.lock
Untracked files:
(use "git add <file>..." to include in what will be committed)
php.ini
php_errorlog
These changes makes my git pull failed thus need to commit it first before pulling the updates from GitLab repository. How should we commit it the right way to prevent conflict on server side.
This is actually the scenario:
First I push my changes from local development machine to Gitlab repository. git command git push
Second I pull code updates from Gitlab repository to my server. git command git pull
Third I get conflict due to uncommitted changes in server.
Error conflict: after done the second step.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: .htaccess
modified: composer.json
modified: composer.lock
Untracked files:
(use "git add <file>..." to include in what will be committed)
php.ini
php_errorlog
NOTE : If multiple people are working on the same file, then there is more possibility of getting conflicts. It will be easy to resolve conflicts with Visual Studio Code Editor
Steps to resolve conflicts
Check whether all your change set are correct , validate once and remove /discard all the wanted files which you don't want to commit
Enter the command in current work folder git add .
Then check the staged file with the next command git status and validate once like whether the required file only got staged up.
Then do git stash, which will store your current code with another index
Now do git pull to pull the changes from the server, which will make your current working repository latest with server
Now do git stash pop , this will stash the changes which you have done
Since you have poped out your changes , if any conflict occurs check the changeset
if both are needed - do Accept Both,
if only your changes needed - do Accept Incoming,
if the current changes present in server is needed - Accept Current.
Again check git status, by this you can reverify whether only your changeset is correct
Now you can commit your changes to the server
Hope this would be helpful
Last week I created a Github repo and forgot to select a license for the repo. Now there are already 3 large commits.
I have asked the 3 contributors if it is ok if I delete the repo and then create it again with the same name and this time selecting the license when creating the repo, and they were fine with that.
Question
Is there a way I can get the commits into the new repo (this time the first commit is the LICENSE file) and still keep the commit meta info?
Is there a way I have get the commits into new repo (this time the first commit is the LICENSE file) and still keep the commit meta info?
Yes, by adding a remote and cherry-picking the commits on top of your first commit.
# add the old repo as a remote repository
git remote add oldrepo https://github.com/path/to/oldrepo
# get the old repo commits
git remote update
# examine the whole tree
git log --all --oneline --graph --decorate
# copy (cherry-pick) the commits from the old repo into your new local one
git cherry-pick sha-of-commit-one
git cherry-pick sha-of-commit-two
git cherry-pick sha-of-commit-three
# check your local repo is correct
git log
# send your new tree (repo state) to github
git push origin master
# remove the now-unneeded reference to oldrepo
git remote remove oldrepo
The rest of this answer is if you still want to add the LICENSE to your previous repo.
Yes. You can place your LICENSE commit as the first commit by rebasing.
Rebasing is gits way of rearranging commit order while keeping all the commit authors and commit dates intact.
When working on a shared repo, it's generally discouraged unless your entire team is git-fluent. For those that aren't, they can just clone a fresh copy of the repository.
Here's how you get your LICENSE commit as the first commit.
1. Update and rebase your local copy
Check out your project and place the LICENSE file in a commit ON TOP of your current 3 commit stack.
#create LICENSE file, edit, add content, save
git add LICENSE
git commit -m 'Initial commit'
Then do an interactive rebase on the master branch to REARRANGE the commits.
git rebase -i --root
It will open an editor. Move the bottom line (your "Initial commit" commit, the most recent commit) to the top of the file. Then save and quit the editor.
As soon as you exit the editor, git will write the commits in the order you just specified.
You now have your local copy of the repository updated. do:
git log
to verify.
2. Force push your new repo state to github
Now that your copy is updated, you have to force push it to github.
git push -f origin master
This will tell github to move the master branch to its new location.
You should only force push in rare occasions like this where everybody working with it is aware of the pending change, else it will confuse your collaborators.
3. Synchronize collaborators to github
Lastly, all the collaborators will have to synchronize to this repository.
First they must have clean repositories as the following command can be destructive if there are unsaved changes.
# make sure there are no unsaved changes
git status
# pull the latest version from github
git fetch
# move their master branch pointer to the one you published to github.
git reset --hard origin/master
That's it. Everybody should be in sync now.
I had a similar problem where I forgot to fork a repo to my github and added several commits before I realized my mistake.
I found a pretty simple solution.
First remove the remote to the original repo
git remote remove origin
Second add a remote to the new fork on my github
git remote add origin <my repo URL>
Then I pushed to origin master and all of my commits showed up on my github.
I used the following approach:
Clone the source repo to a folder like /c/SrcRepo
Clone the destination repo to a folder like /c/DstRepo and switch to the destination branch
In the root folder of the destination repo run the command:
git pull /c/SrcRepo srcBranch --allow-unrelated-histories
No necessary to create an additional remote reference
Based on #Moocowmoo's answer but trying to streamline it bit more
What this does differently is tries to avoid conflicts as much as possible, just assuming that the remote is correct.
It doesn't however handle deleted files well, so there is still a manual element.
# assuming you are already on the branch you want to be
git remote add oldrepo https://github.com/path/to/oldrepo
git fetch oldrepo
# take all or subset of changes from a branch
git cherry-pick --strategy recursive --strategy-option theirs oldestCommitHash^..latestCommitHash
# or take all changes included in a specific merge commit (easiest)
git cherry-pick --strategy recursive --strategy-option theirs mergeCommitHash^..mergeCommitHash
# handling deleted files/unhandled conflicts
# just keep repeating this section
git mergetool
# either c/m or d based on if you want to keep or delete the files
git cherry-pick --continue
Destination Git = UrlD (existing content doesn't matter)
SourceGit = UrlS
git clone UrlS
git remote add origin2 UrlD
git push -f origin2 master
Now the Destination will have the same data as Source(You can also use origin instead of origin2)
you can try this, it's easy and straightforward. This will push all commits before (and including) the hash you use as <last-commit-hash-from-old-repo> to the other repo:
git clone https://github.com/path/to/new-repo.git new-repo
cd new-repo
git remote add old https://github.com/path/to/old-repo.git
git remote update
git merge --allow-unrelated-histories <last-commit-hash-from-old-repo>
git push origin main
if anyone needs to push all commits from a repo to another as a single commit (like I needed), you can simply add --squash to the merge command like this:
git clone https://github.com/path/to/new-repo.git new-repo
cd new-repo
git remote add old https://github.com/path/to/old-repo.git
git remote update
git merge --squash --allow-unrelated-histories <last-commit-hash-from-old-repo>
git push origin main
In my case I needed to find out differences between the old and new repos. So in the new repo added the old one.
git remote add old https://gitlab.site.az/old-blog.git
Fetch all remotes
git fetch --all
Find different commits
git log --graph --oneline --pretty=format:"%h%x09%an%x09%ad%x09%s" --abbrev-commit --date=relative develop..old/develop
Get commits you selected
git cherry-pick SHA1 SHA2 SHA4
I've probably just lost 5 hours of work here... :(
I was on branch A: Created new file with other changes to existing files
I stashed my changes
Checked out master
Did pull on master
Checked out branch A
Did git stash apply
Did git checkout -b newBranchB
I then did git rebase master
Due to some conflicts I then did git rebase --abort
Prior to aborting and rebasing, I can see the new file.
I don't see my new file after aborting rebase! :(
see if git reflog has it.
git log records all commits that will be pushed to the remote repo.
get reflog shows all commits, even squashed commits - amended commits, overwritten commits, etc (but only since u last cloned).
git reflog
git reset --hard YOUR_REFLOG_COMMIT
i just hope u committed at some point!
note that git reflog is a local reference and is deleted if you delete the git folder locally. unlike git log, which will be available if you delete the git folder locally and then clone the repo again later.
I'm new to Git. We're in Linux, and I just inherited someone's project family.
I recently did:
git add Bom.xml Bom.csv N.cpp makefile ../mm
git commit -a
(said On branch Bom, your branch is ahead of master by 2 commits. use git push to publish your local commits. Untracked files: list of things I don't want to commit anyway). Nothing added to commit but untracked files present.
then
git push
But it said everything up-to-date. I'm not sure where to look to see that my content is pushed up to my branch on the server. I know I had file changes since my last commit. It's a tough thing to search for the answer online. I looked at up-to-date too, and added the git add and the -a to my commit, but it still says up-to-date when I try to push.
Thanks!
Mich
Like the link you mentioned, make sure you have added the file you want to commit into the staging area. Each time you want to commit
run git status to check.
And then run git add file to add file to staging area.
Run git status to check whether the file is added to the stage.
Then run git commit -m "some message" to commit
run git log to check your commit history check whether you have committed successfully
then check your remote branch by running git branch -a
if your remote branch doesn't have your local branch branch-name
then run git push origin branch-name to push your local branch to remote.