If i started working on a feature from mainline and I make 1 commit. However, by the time i finish the mainline has been committed 5 more times.
Is it considered that I branched? even though i didn’t create a branch? if so, what would my branch be called? git status shows it still called mainline.
How do i sync to mainline. I read that rebase is the scenario i am in. when inrebase, it says rebase complete and up to date, however i do not see the latest changes of the other commits in my source code.
CodePudding user response：
There is two branch the local one and the remote one, classic way and easy way is to name local and remote with the same name.
So in your case, you are in this situation
A---B---C---D---E mainline on the server
/
X---Y---Z mainline
but for your local git doesn't know the update on the server, it has this vision
X---Y origin/mainline
\---Z mainline
so all is ok, you local git needs to fetch the new status of origin/mainline with
git fetch
will brink you in this situation on your local git
A---B---C---D---E origin/mainline
/
X---Y---Z mainline
Then you will be able to merge or rebase your branch:
- merge
A---B---C---D---E origin/mainline
/ \
X---Y---Z---------------M mainline
- rebase:
X---Y---A---B---C---D---E--Z' mainline
I recommend rebase in your case
CodePudding user response：
Is it considered that I branched?
Yes, no, and/or maybe. The problem here is the word branch. See also What exactly do we mean by "branch"?
if [we wish to call it a branch], what would my branch be called? git status shows it still called mainline.
Yes, your branch name is mainline. Their branch's name is mainline. Nonetheless, these are different names.
Have you ever been at a gathering of people where more than one person has the same name? This is the same kind of problem. Even if everyone is named Bruce, they're still different people. It makes sense to say "Hey Bruce, Bruce told me to tell you that Bruce is waiting for you." These are three different people, all named Bruce.
In the same manner, you and they have different "branches" (for some meaning of branch), both named mainline.
As Ôrel noted, if you run:
git fetch origin
your own Git software will reach out to GitHub's Git software—assuming the other repository here is on GitHub; if not, insert some other name as needed—and ask their software for any new commits they have on their mainline. They will send them over, and your Git will add these commits to your repository, so that now you have their new-to-you commits.
When your Git—by which I mean your software working with your repository—gets commits from their Git, your Git changes their branch names, such as mainline, into your remote-tracking names such as origin/mainline. This helps with the "everyone's called Bruce" problem: now instead of telling Bruce that Bruce is waiting for him, you can tell Bruce Ashford that Bruce Billington is waiting—or in this case, you can ask your Git about origin/mainline and see the commits on their mainline, which your Git is remembering as your origin/mainline.
It's very important to realize that your Git and their Git only talk to each other when you make them do it. You run git fetch to have your Git call them up over the Internet and get commits from them. You run git push to have your Git call them up over the Internet and send commits to them. Note, too, that this works commit-by-commit. There's no issue with individual files here: you get, or send, a whole commit. You either have the entire commit, or none of it.1
There's one other oddity, which is that when you get commits, you get these remote-tracking name thingies—these origin/* names. But when you git push to send commits to them, you don't have them set some sort of tracking name. You ask them, politely, if they could please set their branch name. That is:
git push origin somebranch
has your Git talk to their Git, figure out which commits you have on your branch somebranch that they don't have, send those commits over, and then ask them to create or update their branch name somebranch directly. If they do that, your Git updates your origin/somebranch—your memory of their somebranch—to match. If they say no, I won't do that because _____ (they're required to fill in this blank, to tell you why they won't) then your Git doesn't update any remote-tracking name here.
If they say they won't, you can use a forceful git push that turns the polite request into a command, but be aware that if they obey that command when they wouldn't obey a polite request, it probably means that you've told them to drop some commits: that's probably the reason they filled in when they said no to the polite request. Git has a funny (weird) term for this, "non-fast-forward", but that's what it means: no, I won't set my branch because doing so will lose some commits. You should force this if and only if you're sure that losing those commits is the right thing, and that's rare except for one case involving git rebase (which we won't go into here).
1A fancy new feature called a partial clone pokes a deliberate hole in these rules. Partial clones are a nice optimization sometimes. However, there are a lot of rough edges here. For instance, partial clones can be a terrible pessimization sometimes. Don't use them (yet) unless you really understand what you're getting into.