I committed a change in my file and want to sync it. I am using the Windows Github user interface and I am new to this. The sync button does not show up. How can I do this with a shell command?
If you look at the screenshot, near the top it says detached head. Although rather unpleasant sounding, this just means that you're not on a branch but rather having a commit checked out.
Looking at one of your comments, it says rebasing master. Looks to me like a rebase was started, but never finished. If you haven't touched the command line, this sounds like a bug in GitHub for Windows, and I'd report it to GitHub support. It should still be possible to clean this up though.
If you type git status in the command line, you should get something like this (this is on Linux, it may look slightly different on Windows):
[~/dev/cost_model] git status
# Not currently on any branch.
# You are currently rebasing branch 'master' on '174ffcb'.
# (fix conflicts and then run "git rebase --continue")
# (use "git rebase --skip" to skip this patch)
# (use "git rebase --abort" to check out the original branch)
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: some/path/to/a/file
#
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add <file>..." to mark resolution)
#
# both modified: some/other/path/to/a/file
#
The files under "Changes to be committed" are fine, and were rebased just fine. If you have any files under "unmerged paths", though, you should open them and check for merge conflicts (they are sections of the code that begin with "<<<<<<<" or something similar, just open the file and make sure the file ends up looking like you want it to).
Once you've resolved all conflicts, run git rebase --continue. Check the message that appears, there may still be conflicts.
Another option is to run git rebase --abort to stop the rebase if you didn't want it to finish.
Once you're done, you should be back on your branch and be able to sync.
Try: git push origin {branch_name}
Related
Is there any way of simulating a git merge between two branches, the current working branch and the master, but without making any changes?
I often have conflicts when I have to make a git merge. Is there any way of simulating the merge first?
You can use git merge --no-commit to prevent the merge from actually being committed, and if you don't like how the merge works out, just reset to the original head.
If you definitely don't want to finalize the merge, even if it's a fast-forward (and thus has no conflicts, by definition), you could add --no-ff as well.
I don't think there is a way of simulating what will happen until you try the merge. However, if you make sure that the output of git status is empty before you do the merge, it is quite safe to just go ahead and try it. If you get conflicts, you can immediately get back to the state you were at before with:
git reset --merge
Since git 1.7.4, you can also abort the merge by doing:
git merge --abort
(As the commit message that added that option explains, this was added for consistency with git rebase --abort and so on.)
If I want to compare changes on a topic branch to master, I find it easiest and safest to do the following:
git checkout master
git checkout -b trial_merge
git merge topic_branch
After completing the merge, it is easy to see the consolidated change from master
git diff master
When done, simply delete the trial_merge branch
git checkout master
git branch -D trial_merge
This way, the master branch never changes.
Here is the solution that I have found: git merge-tree does merging "in memory" and prints the diff without touching your working directory. You can even test a branch without checking it out.
Get the merge diff
First, do this to make sure your repository knows about all the remote branches:
$ git fetch --all
Now use this bash snippet to see how branch $branch would merge into $master:
$ branch='feature'
$ git merge-tree $(git merge-base $branch master) master $branch
No changes are made to your workdir or index. It's a dry-run merge.
Pick information from the output
The output is a diff.
In case the branch has been merged, it will be empty.
To find whether there are conflicts, grep it for <<<:
$ git merge-tree $(git merge-base $branch master) master $branch | fgrep '<<<'
To extract conflict diffs, use sed to extract lines between <<< and >>>:
$ git merge-tree $(git merge-base $branch master) master $branch | \
sed -ne '/^\+<<</,/^\+>>>/ p'
Features
The diff will be empty if a branch is already merged
Use grep/sed to extract conflicts information
Use origin/feature to test branches you've never worked with
Can be used to see how 2 branches have diverged
Add it to your favorites
Get the diff of the merge:
git config --global alias.mergediff '!f(){ branch="$1" ; into="$2" ; git merge-tree $(git merge-base "$branch" "$into") "$into" "$branch" ; };f '
Usage:
$ git mergediff <feature-branch> <merge-into>
$ git mergediff feature master
Get merge conflicts:
git config --global alias.mergetest '!f(){ git mergediff $# | sed -ne "/^+<<</,/^+>>>/ p" ; };f '
Usage:
$ git mergetest <feature-branch> <merge-into>
$ git mergetest feature master
Why not just create a throwaway branch (git checkout -b), and do a test merge there?
I use :
git merge --ff-only
according to documentation:
Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.
It's not really a simulation because there will be a fast-forward merge in case of no conflicts between the two branches. But in case of conflicts, you will be informed and nothing will happens.
I've been able to use git merge --abort, recently. However, this can only be used if there is a merge conflict. If you are sure that you will not want to commit, then use the other mentioned methods above.
I don't know exactly if it is your case, but your question remember me that sometimes I start a feature, I commit over the days and I merge the develop on it many times.
On this point I lose the control over the exact files I changed and I will only know it when my feature were closed and my code go to develop.
In this case, a good way to know what modifications you did (not other from the merges) is using Sourcetree.
You must click with the right button on the base branch and select Diff Against Current:
Then sourcetree will show you all the modifications that will be merged if you merge your branch into base branch.
Of course, it will not show you the conflicts, but it is a useful tool in merges.
I am using Xcode's integrated Source Control with Git and I have the following problem:
I have a perfectly working master branch and I want to work on two new features. So I create two new branches, where I add one new file at each branch.
Now when I switch back to the master branch or the other branch, after committing the changes and without merging (I don't want to merge yet), the files from ALL the branches appear in the project navigator (the ones that don't belong to the current branch are in red colour) and prevent my code from compiling as the compiler complains that these files don't exist.
My master at least should compile regardless of what I've done in other branches right?
Am I missing something trivial here?
Untracked files and unstaged changes do not belong to any branch. They only live in your working tree. When you switch branches, those files/changes are left untouched. If you want them to exist only in a certain branch, you have to add and commit all of them.
This should help understanding:
$ git status
On branch master
nothing to commit, working directory clean
$ >>file echo 'added line'
$ touch new_file
$ git status
On branch master
Changes not staged for commit:
modified: file
Untracked files:
new_file
$ git checkout -b new_branch
M file
Switch to a new branch 'new_branch'
$ git status
On branch new_branch
Changes not staged for commit:
modified: file
Untracked files:
new_file
So, as you see, unstaged changes are carried over when switching branches (this is by design). When checking out another branch, Git tells you which files contain changes (the line starting with Modified). This also holds for untracked files (Git cannot delete them, since you might need them), but their names are not explicitely output when checking out a branch.
To have Git delete files when switching a branch, you have to add (and commit!) them to a branch first.
IM getting this error message that says syncing has failed. I looked around for solutions and found that git status would give some idea about the problem. So I did it and got this:
# On branch dev_0.9_HUD_development
# Your branch is behind 'origin/dev_0.9_HUD_development' by 1 commit, and can be
fast-forwarded.
# (use "git pull" to update your local branch)
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: res/models/hud/HUD2.png
# modified: src/Weapon/Laser.java
# modified: src/Weapon/Weapon.java
# modified: src/game/world/gui/hud/HeadsUpDisplay.java
# modified: src/game/world/gui/hud/ShipStat.java
# modified: src/game/world/gui/hud/WeaponDisplay.java
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# src/hero101.mtl
# src/hero101.obj
There were many solutions but none of them seem to work. I tried restarting computer. Nothing happened. I tried git checkout but it gives another error. I tried merging the branches still get the same error. What can I do to fix this?
If your branch is behind an upstream remote branch, that means you haven't done any commit.
In command line:
cd /patH/to/your/repo
git stash
git pull
git stash pop
git add -A
git commit -m "My work"
git push
That assumes that all the files listed by your current git status are modified files that you want to version.
Ok. So i looked into the .git folder in the repo. I changed the name of index.lock file, after that i did the git stash and git pull and everything worked.
I can never seem to figure out how to use git. I just do random commands and it works eventually. This is what I usually do when I want to push:
Fetch from upstream
Commit
Push to upstream
However, the above steps don't work sometimes. For example, when I do fetch from upstream, my local branch doesn't get updated.
How do I merge the remote branch into my local branch? Is there a difference between pull and fetch?
"git pull" is equivalent to "git fetch" followed by "git merge"
What you want to do is:
git commit -am "your message here"
This commits your current changes locally, and only locally. Now, assuming branch "foo":
git pull origin foo
This does a "git fetch" followed by a "git merge". Everything in this step is done to your local branch, and still has no effect on the remote branch. Depending on how your git is setup, you might need to specify the branch.
If you have a merge conflict, you will have to fix the files listed, then add them back:
git add path/to/resolved.file
When you are done, push everything you have from your local changes, to the remote server:
git push origin foo
If you pull before committing, that might cause your local branch to not be updated.
tl;dr, always commit before pulling!
Well to understand differences betwene git fetch and git pull look here.
In the simplest terms, "git pull" does a "git fetch" followed by a
"git merge".
You can do a "git fetch" at any time to update your local copy of a
remote branch. This operation never changes any of your own branches
and is safe to do without changing your working copy. I have even
heard of people running "git fetch" periodically in a cron job in the
background (although I wouldn't recommend doing this).
Working with git in eclipse might be a little bit tricky, but if you understand git basics, you should cope with it. I recommend you to read one of git tutorials, so you will be able to understand basic git operations.
The first step to learn git: Don't use egit.
Now, you are fetching and pulling from upstream. That makes me think that several people have write-access to the same repository, so we probably don't want to be doing a whole lot of merges to complicate history. It would be best to do this. I'm assuming you have already committed a changes or a set of changes to your local master branch that you want to place on the upstream repository which has been pushed to by someone else while you were making your commits.
First, we fetch the new changes but don't use them yet. This updates upstream/master to the new head of the upstream master branch.
git fetch upstream master
Now, we need to pull in these changes. This command rewrites history, and we are assuming
that you have not published your changes anywhere yet.
git rebase upstream/master master
If you have published your changes, this messier command is the one you should use (do not use both, just use this one!)
git merge upstream/master master
Now, we can push:
git push upstream master
The first two steps can be shorted to git pull --rebase and git pull for the rebase and merge versions respectively.
If you are already on the master branch, most of those second arguments are superfluous but I wrote them in for clarity. Notably, giving a second argument to git-rebase or git-merge will simply check out that branch before doing the operation. Supplying master to fetch and push is only necessary if you don't have the refs set up to automatically fetch and push master.
Specifically, I'm using bzr, but tips for any VCS are welcome.
I think there are three options.
Use shelving
bzr shelve --all
bzr unshelve
Create a separate branch with the
latest
Create a patch of you
changes and revert the changes.
Apply patch when you need your
changes back.
Using Git:
git checkout HEAD^ # get the previous version, changing files on disk to match
make # run your project (or whatever command you use)
git checkout master # return to the "master" branch
The above applies if you've already committed whatever current changes you're working on, and want to go back to the previous commit. If you have changes that have not been committed yet, then use the stash:
git stash # save the uncommitted changes away
make # ...
git stash pop # restore your uncommitted changes
You can make and commit other changes in between the stash and the pop; this is Git's solution to the "boss interrupts with an immediate bug fix request" problem.