Why does Git say my master branch is "already up to date" even though it is not?
I think your basic issue here is that you’re misinterpreting and/or misunderstanding what git does and why it does it.
When you clone some other repository, git makes a copy of whatever is «over there». It also takes «their» branch labels, such as master , and makes a copy of that label whose «full name» in your git tree is (normally) remotes/origin/master (but in your case, remotes/upstream/master ). Most of the time you get to omit the remotes/ part too, so you can refer to that original copy as upstream/master .
If you now make and commit some change(s) to some file(s), you’re the only one with those changes. Meanwhile other people may use the original repository (from which you made your clone) to make other clones and change those clones. They are the only ones with their changes, of course. Eventually though, someone may have changes they send back to the original owner (via «push» or patches or whatever).
The git pull command is mostly just shorthand for git fetch followed by git merge . This is important because it means you need to understand what those two operations actually do.
The git fetch command says to go back to wherever you cloned from (or have otherwise set up as a place to fetch from) and find «new stuff someone else added or changed or removed». Those changes are copied over and applied to your copy of what you got from them earlier. They are not applied to your own work, only to theirs.
The git merge command is more complicated and is where you are going awry. What it does, oversimplified a bit, is compare «what you changed in your copy» to «changes you fetched from someone-else and thus got added to your-copy-of-the-someone-else’s-work». If your changes and their changes don’t seem to conflict, the merge operation mushes them together and gives you a «merge commit» that ties your development and their development together (though there is a very common «easy» case in which you have no changes and you get a «fast forward»).
The situation you’re encountering now is one in which you have made changes and committed them—nine times, in fact, hence the «ahead 9″—and they have made no changes. So, fetch dutifully fetches nothing, and then merge takes their lack-of-changes and also does nothing.
What you want is to look at, or maybe even «reset» to, «their» version of the code.
If you merely want to look at it, you can simply check out that version:
That tells git that you want to move the current directory to the branch whose full name is actually remotes/upstream/master . You’ll see their code as of the last time you ran git fetch and got their latest code.
If you want to abandon all your own changes, what you need to do is change git’s idea of which revision your label, master , should name. Currently it names your most recent commit. If you get back onto that branch:
then the git reset command will allow you to «move the label», as it were. The only remaining problem (assuming you’re really ready to abandon everything you’ve don) is finding where the label should point.
git log will let you find the numeric names—those things like 7cfcb29 —which are permanent (never changing) names, and there are a ridiculous number of other ways to name them, but in this case you just want the name upstream/master .
To move the label, wiping out your own changes (any that you have committed are actually recoverable for quite a while but it’s a lot harder after this so be very sure):
The —hard tells git to wipe out what you have been doing, move the current branch label, and then check out the given commit.
It’s not super-common to really want to git reset —hard and wipe out a bunch of work. A safer method (making it a lot easier to recover that work if you decide some of it was worthwhile after all) is to rename your existing branch:
and then make a new local branch named master that «tracks» (I don’t really like this term as I think it confuses people but that’s the git term 🙂 ) the origin (or upstream) master:
which you can then get yourself on with:
What the last three commands do (there’s shortcuts to make it just two commands) is to change the name pasted on the existing label, then make a new label, then switch to it:
before doing anything:
after git branch -m :
after git branch -t master upstream/master :
Here C0 is the latest commit (a complete source tree) that you got when you first did your git clone . C1 through C9 are your commits.
Note that if you were to git checkout bunchofhacks and then git reset —hard HEAD^^ , this would change the last picture to:
The reason is that HEAD^^ names the revision two up from the head of the current branch (which just before the reset would be bunchofhacks ), and reset —hard then moves the label. Commits C8 and C9 are now mostly invisible (you can use things like the reflog and git fsck to find them but it’s no longer trivial). Your labels are yours to move however you like. The fetch command takes care of the ones that start with remotes/ . It’s conventional to match «yours» with «theirs» (so if they have a remotes/origin/mauve you’d name yours mauve too), but you can type in «theirs» whenever you want to name/see commits you got «from them». (Remember that «one commit» is an entire source tree. You can pick out one specific file from one commit, with git show for instance, if and when you want that.)
I had the same problem as you.
I did git status git fetch git pull , but my branch was still behind to origin. I had folders and files pushed to remote and I saw the files on the web, but on my local they were missing.
Finally, these commands updated all the files and folders on my local:
or if you want a branch
Any changes you commit, like deleting all your project files, will still be in place after a pull. All a pull does is merge the latest changes from somewhere else into your own branch, and if your branch has deleted everything, then at best you’ll get merge conflicts when upstream changes affect files you’ve deleted. So, in short, yes everything is up to date.
If you describe what outcome you’d like to have instead of «all files deleted», maybe someone can suggest an appropriate course of action.
Update:
GET THE MOST RECENT OF THE CODE ON MY SYSTEM
What you don’t seem to understand is that you already have the most recent code, which is yours. If what you really want is to see the most recent of someone else’s work that’s on the master branch, just do:
Note that this won’t leave you in a position to immediately (re)start your own work. If you need to know how to undo something you’ve done or otherwise revert changes you or someone else have made, then please provide details. Also, consider reading up on what version control is for, since you seem to misunderstand its basic purpose.
Помогите расколдовать проблему с веткой в git.
Значит такая ситуация. Создал я как то ветку, в своём простом локальном репозитории( от ветки master). Менял код, вёртску. Не помню чего страшного я сделал(git исп-ю не часто), появилась у меня такая вот ситуация:
Ты видимо откатился на определенный коммит. Типа того:
Простой вариант — копируешь все файлы в другой каталог (кроме .git), а потом делаешь git checkout <имя ветки, что тебе нужна>. После этого убиваешь все файлы, кроме .git и копируешь забекапленые. Потом их коммитишь.
Минус подхода — ты теряешь историю своих изменений.
Если предположить, что ты был в ветке xxxxx, а потом просто сделал git checkout <коммит yyyyyyyyyyyyyy> и далее коммитил, то тебе будет достаточно сделать git merge xxx, чтобы вернуть изменения в xxx.
git checkout <коммит yyyyyyyyyyyyyy> переводит тебя в detached head, т.е. ты как бы в неназванном бренче, который ты отделил от какого-то коммита. Твое состояние можно идентифицировать по номеру последнего коммита в git log (который в самом начале). Вернуться в это состояние всегда можно через git checkout с тем номером коммита. В такой бренч можно делать коммиты, но ты их потеряешь, если уйдешь с бренча и забудешь номер коммита.
появилась у меня такая вот ситуация:
Это detached state. Это означает то, что твой коммит находится вне бранча.
Причём я делал git push/git pull в ответ «Everything up-to-date»/«Already up-to-date» соответственно
Логично, потому как пушить нечего (HEAD’ы локальный бранчей не отличаются от HEAD’ов ремоутных бранчей).
Крайне не хочу потерять изменения. Помогите разобраться!
Нужно сделать следующее:
— застэшить изменения (ресетнуть коммит через git reset —soft, перевести из их в unstage, сделать git stash);
— перепрыгнуть на коммит, на который указывает HEAD интересующего бранча (git co master);
— git stash pop
Есть и другое решение.
— запомнить хэши коммитов
— перепрыгнуть в нужный бранч
— почерепикать коммиты друг за дружкой (man git-cherry-pick)
Why is Git falsely noting that my files are up-to-date?
I have two folders—A and B—in my file directory that link up to the same Git repository.
I created a file in folder A called index.html . I then create a different file also called index.html in folder B. I then add index.html in folder B, commit, and push B’s contents.
When I pull from folder A, Git claims that my files are «Already up-to-date.» However both folders clearly have different index.html files. What is going on?
4 Answers 4
git pull ‘s job is to fetch new commits and merge them into the current branch. If the current branch is not outdated compared to the one you pull from, pull will say Already up-to-date. even if you have local changes in your working directory. git pull is concerned with branches, not the working tree — it will comment on the working tree only if there are changes which interfere with the merge.
Your description is insufficient to explain why it’s not objecting to the existing index.html , but you should not take Already up-to-date. as meaning git thinks you have no changes. Instead, use git status to obtain a summary.
In order to understand the state of your branches, git branch -v is useful (it shows the commit ID and relation to each branch’s upstream branch), or gitk —all for a graphical view of all commits.
If I understand correctly the following script should reproduce your issue:
Solve Git Push Everything Up-To-Date Issue
Git is a free and open-source version control system designed to handle projects quickly and efficiently. You can change your repo and push it to the master branch.
This article explains how to solve the everything up-to-date issue when you use the git push command after making changes to the repo.
Push Changes With Git
The Git tool allows you to change your repo and push those changes to the branches. Typically, to push the changes, you should follow the steps below.
However, sometimes you can see Everything up-to-date output when you want to push your changes after committing them to the local repo. The rest of the article examines the possible causes of this issue.
Problems With the git commit Command in Git
You must use the git commit command before using the git push command. Also, you must add the -m option to the command.
The -m or —message option uses the given message as the commit message.
As the example above shows, not using the -m option throws an error, and changes cannot be pushed.
Problems With Branch Names in Git
If you do not give a branch name as an argument to the git push command, the main branch is selected by default.
If the branch you want to push changes to is different, specify it. Otherwise, you may get an error.
This problem may also occur if the local branch name is different from the remote branch name. Make sure you use the correct names.
However, typing these branch names over and over can be annoying. You can set upstream between the local and remote branches to avoid this.
Problems With Detached Head in Git
If your latest commit is not a branch head, you may get this error. To fix this, follow the steps below.
To save your files, use the git stash command. Then look at the log and get the SHA-1 of the latest commit.
Reset the branch head to previously detached commit with the git reset command. It gets everything from the current folder and creates all the branches on the local machine.
Yahya Irmak has experience in full stack technologies such as Java, Spring Boot, JavaScript, CSS, HTML.