Git remote branch commit - eclipse

I have forgot to create local branch and was working with remote. After making some changes, i by mistake using Eclipse Git plugin commit this branch in nowhere(obliviously there wasn't local branch). And after that i switched to master, and lost all changes.
So how i can restore my changes?

Use git reflog, you'll see previous commit's IDs (in order of commit-time, from most recent to older), and you will then be able to rebase on top of them (or use them like any other commit, that is).
The reflog is the last place you can recover commits that cannot be reached from the tip of any (local) branch, and commits will stay there in the limbo until they are eventually garbage collected, which theoretically could happen any time.

Related

Egit: You are in detached head state. This means that you don't have a local branch checked out

I recently created a project on Eclipse. I set up a git repository on the project. Pushed the code to a new repository on GitLab.
I checked out (Import->Project from Git) the project to another laptop, made updates, committed it as another author and pushed it back to repository (2nd commit /revision). I only removed the target runtimes from the project as the changes.
I went to my 1st laptop and wanted to try update / pull my code. I right-clicked on the repository from the Git Repository view -> Remote -> Fetch. I entered the path to the repository and etc and fetched the repository. But, my project still has the old code having the target runtime. I know I only 'fetched' the repository, not 'pulled' maybe.
So I was confused, the code was not updated. If I am not mistaken, I right-clicked the repository again, clicked on 'Check Out'. This was the result :
After 'Checkin Out', the target runtimes on my project were removed, updated like from the 2nd commit. But there are now 2 branches and 2 refs. I don't what state my local repository is in now. And/but the local master branch was still in 'initial commit', isn't it confusing?.. My code has been updated..
I only read a bit of the git manual online, and I haven't yet be able to wrap my head around concepts like refs.
I could just delete the project and Import->Project from Git, right?
But if I can I would like to know what happened to my project (local repository) and how to fix this?
Thx
I'm not familiar with egit and its menus. But I try to answer your question with git commands which you can run in the console. And I think you can figure out which egit menu items are corresponding to these commands.
You wanted to pull and update the local master in the first laptop repository. You needed git checkout master first, which could be skipped if you were already on master and then git pull origin master. However you did git fetch origin master instead, which just updated origin/master with the new commit. It would have been okay to use git fetch origin master if git merge FETCH_HEAD or git merge origin/master followed imediately, because in many cases pull = fetch + merge, but you didn't.
I guess you then did git checkout origin/master. Checking out origin/master leads to detached HEAD state. To make it easier, you could just consider the detached HEAD as a nameless branch. When you make new commits, this namelss branch will grow. But you can't see these commits on other branches unless you apply these commits to them. Git has some commands to apply commits, including git merge, git rebase, git cherrypick, etc.
To fix the current situation, you can simply run git checkout master;git pull origin master.
So to make my answer more simply. Commit changes on your deateached head and make branch with this commit and then merge it together and push to master.
You can just download again your project if you didn't make changes on detached head that you need.

GitHub: Commit a point in history as the head of master

There is a certain commit I did to my Git repository which I host in GitHub. After that commit I've made several other commits, which were bad and redundant, in a second look. I thus need to revert to the certain commit / certain point in history before these bad changes.
I didn't find a button like "revert to this version" or "commit this version as the head of this branch (master)".
As you can see, I just want to make that older version the head of the master branch. How will you do that from GitHub?
Update
I emphasize: I ask on GitHub, not on git or any GUI other than GitHub.
If I understand you correctly you want a past commit as the last commit on the branch.
If so, using examples with origin and master:
Use git reset <comit_id> and then git push origin +master to push & delete all commits past the one you reset to. Notice the + sign before the branch name (master).
Note that this is irreversible (as far as I know) so take the necessary precautions.

Eclipse Git (EGit) - How to revert local master back to remote master after a foul merge & commit with a local branch

I have the following setup:
Remote origin/master (default branch)
Locally, I got the master and created another branch - NewBranch.
Someone in my team updated master on the remote. I was able to pull in all the changes that they made.
However, while merging I had conflicts. Unintentionally, instead of updating NewBranch with the conflicted result, I have updated the local master with NewBranch (because master was the one that was currently checked out-or "active" in Eclipse). Furthermore I committed this change (locally) to my local master branch...
I was able to switch to NewBranch and merge it with all the latest changes (so my Newbranch is perfectly the way I want it).
Now, I'd like the master to point to the same version as remote master does.
So that in the future I have a clean merge between my NewBranch and the Master
I've tried to "Reset" the master, but after performing a hard reset, the Hash Ids b/w the local master and remote master still do not match.
I also have References in my git eclipse and the reference of FETCH_HEAD is the one I'd like my master to revert to.
How can I do this using git in Eclipse?
Thanks in advance
I am guessing you are asking these 2 questions?
Now, I'd like the master to point to the same version as remote master
does
If I'm right follow this, if you master should point to remote master
git pull origin master
If your NewBranch should point to remote master
git pull origin NewBranch
I also have References in my git eclipse and the reference of
FETCH_HEAD is the one I'd like my master to revert to.
Please right-click on project in your eclipse--->go to team----> check the git options
These commands will help you to revert to a specific commit
git checkout master
git reset --hard e3f1e37
git push --force origin master
# Then to prove it (it won't print any diff)
git diff master..origin/master
Alternative
Sometimes you may want to undo a whole commit with all changes. Instead of going through all the changes manually, you can simply tell git to revert a commit, which does not even have to be the last one. Reverting a commit means to create a new commit that undoes all changes that were made in the bad commit. Just like above, the bad commit remains there, but it no longer affects the the current master and any future commits on top of it.
git revert ~specificCommit
But remember this after git revert, if you want to go back, you need to read this Git revert be careful
before you do it.
git revert 45ae34 e34526a #created two revert commits
git revert HEAD~2..HEAD #by taking ranges, it will revert last 2 commits
git revert -m 1 <merge_commit_sha> #this basically reverts a merge commit
# To get just one, you could use `rebase -i` to squash them afterwards
# Or, you could do it manually (be sure to do this at top level of the repo)
# get your index and work tree into the desired state, without changing HEAD:
git checkout 34e2w34 .
git commit #commit here
Docs:
git docs: undo merges

How to switch branches in eclipse without commiting changes

I've been using GIT for a couple of weeks now and trying to understand how to switch branches without commiting files. This is what I have done.
Cloned a git repository and have a local master branch.
Created a new local branch (Branch2) which is based on a remote branch.
Made changes to 2 files in the master branch.
What I want to do now is switch from master to Branch2.
The changes I made to the master branch are for local dev purposes only and should never be committed.
But when I try to do this in eclipse (i.e I double click on the local branch I try to switch to) it keeps telling me that there are uncommitted changes and I need to commit, stash or reset.
Can anyone tell me how i can make a change to a local file and have git ignore this change so that I don't get prompted with this message?
Note: if you need to stash a work in progress from Eclipse, Egit now supports stash:
Have a look at git stash. Stash allows you to store uncommitted changes.
Option 1
git stash
git checkout -b Branch2
Your changes will be stored in git (locally). When you want to re-apply those changes, you will do git stash pop and it will apply those changes for you.
Option 2
git stash
git stash branch temporarybranch
This will take your uncommitted changes to a new branch and keep them there for you. Compared to the previous option, this allows you to keep these branches on the server by pushing this new branch.
Hope it helps
If you don't want the changes to be ever made public you should just commit them in your own feature branch and not on the master branch.
You can create a new branch, give it a name that reflects the changes, maybe prefix is with something like "experimental-" and then commit to that branch before switching to your other branch.
You can use git stash to stash your changes, or use git stash to commit them directly to a new branch as mentioned by Ege Akpinar.

looking for ideal git-svn workflow

The company that I'm working is working with SVN but I would like to start working with git to take advantage of the light branching and stashing features (disclaimer, I'm pretty new to git). I've started with git-svn and I'm trying to figure out the ideal git-svn workflow for what I'm trying to do (and suggestions if what I'm trying to do needs tweaking).
I've read through git svn workflow - feature branches and merge and a few other posts but its still not clear how I should approach it.
How I plan to work:
I plan on having my master branch be clean from development and only used for merging/rebase/dcommit.
I would like break apart each new feature/bug into separate git branches so they can be worked on independently. Meaning, I can work on one feature for a few hours, then put it aside and work on the next issue. When I was in SVN it was a problem when I had two different features/bugs in one file because when it came time to commit, I would remember that it had both changes and temporarily take out what I didn't want to commit now - a pain.
And the are some features which are while I might want to work on now, will not be added to the main repo for some time.
After a feature is ready to be shared/tested in the main repo, I'll merge/rebase into my master branch and then dcommit to the svn-repo. I only want to have one SVN commit message for each dcommit - I want to be committing in more often with comments more specific to me and then dcommit to svn with a message for the rest of the team. I assume for this I'll either be using a git merge --squash or a git rebase --interactive for this.
The basic git flow I've envisioned is like this:
// it begins...
git svn clone <repo>
//
git checkout -b feature 1
// work commit, work commit
//
git checkout -b bug-123
// work commit, work commit
// bug-123 finished - ready to send back
// got back to master for step 5
git checkout master
// get whatever changes other devs did
git svn rebase
//
git checkout bug-123
// rebase branch so I have fewer smaller changes. not sure here..
git rebase master || git svn rebase
// Assuming I'm doing a FF rebase so my commits are just addons to the current repo
// I don't know if I rebase the master or svn repo or it doesn't matter.
// need to get my changes back to master to send off
git checkout master
// add my changes to master
git rebase bug-123 (--interactive?) || git merge --squash bug-123
// do I add a new commit message here?
// push my changes back out to the team
git dcommit
So there are a few questions:
How should I get the changes into the branch I want to commit - by rebasing the master or the svn branch
how do I get the changes back into the main branch - rebase or merge - remember, I want only one commit for each commit - unless this is going to complicate things - I really would prefer to keep my git commits separate from the SVN commits because I might start something - it's half-working, and want to commit it so I could try something else - but I don't want to commit these broken steps.
would it make sense to dcommit directly from the working branch (eg bug-123)?
how do I get the changes from bug-123 back now into feature-1? I'm assuming I'll do it via the SVN repo - meaning the changes that I added will get merged in when I do the rebase when it's time to add feature-1 to the repo - but maybe not.
I'm no expert, but these are the experiences I've made (related answer).
I think it doesn't matter. The important thing is that you rebase the latest changes from SVN into the branch you are going to dcommit from.
Let other branches receive the changes through SVN. If you want a single SVN commit from a series of git commits, squash them together first.
I think this doesn't matter either. You're going to rebase the latest changes from SVN, and need to get them linearly in front of your Git commits. If you do git svn rebase in master, and then rebase master into a feature branch, or the other way around is same-same. Afterwards you probably want to delete the branch, as it has done its work (as per SVN restrictions, you're not allowed to merge again).
Always let changes flow into other branches and repos through SVN rebasing.
Just try it out and try to get the most simple/practical workflow for you and your team. Try to keep branches short-lived (SVN won't get any notion of them anyway), and remember that the commits must always be linearized at the top of your log before you dcommit back.