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.
Related
hello guys i want to ask about my GITHUB problem, why is my local master branch is different from remote?, i was modifying without committing then git branch -b and git add and git commit, and then after i push the new branch, create pull request, and merged to master, its different when i comeback to local master and git pull
i also already do git fetch origin and git reset --hard origin/master
the code is almost the same as remote but its just weird, a few declaration is missing and one entity naming is the same as my other branch
it turns out, that there is open tab in VSCode that i havent saved from another branch, close it out and dont save it solved the problem
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
I am currently making a project in eclipse.I made changes in head branch and as well as in master branch.I want to merge those changes and push them to remote repository.Please tell me the correct steps so i merge both branches and push the changes to remote repository without getting non fast forward warning.
I am currently making a project in eclipse.I made changes in head branch and as well as
in master branch.
Normally when people refer to "head" they are talking about HEAD, which is not actually a branch but a reference to the "tip" of the currently checked out branch. So if you
git clone foo
cd foo
git checkout bar
assuming bar is a branch, then HEAD would refer to the "tip" or last commit of the bar branch.
If you are getting a non fast forward warning on a push, changes have been made to the remote repository. You to bring those changes into your local branch before you can push.
This is because git requires merge conflicts be resolved in the local repository, not the (usually shared) remote repository. To bring those changes to your local repository you will need to execute a pair of commands; git fetch ... and git merge ... results in a merge commit, which some prefer -- while git fetch ... and git rebase ... if merging the changes without a merge commit is preferred. Note that git pull ... is the same as git fetch ... and git merge ... and git pull --rebase ... is the same as git fetch ... and git rebase ....
Which ever way your prefer, once you get the changes to your local repository (and resolve any conflicts there may be) you will be ready to push.
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.
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.