While I was working on master branch, I created a branch called feature.I switched the branch and I've worked on feature.I finished working on it. Now I want to merge these branches(which are remote) from Visual Studio Code using git.
How can i do it properly without detached head problems,etc.? Thanks
There are no "remote branches" in Git—well, maybe not, or probably not, or "it depends on what the meaning of is is" or other weasel words. For more on why this is, start with What exactly do we mean by "branch"? Note that the word branch is rather badly over-used, and the phrase "remote branch" is now in decline, in favor of "remote-tracking branch name", or as I like to call it now, "remote-tracking name", dropping that pesky word branch altogether.
What we mean by "branch" in Git, then, is one of these:
A branch name like master: this is purely local to your own Git repository. Some other Git repository may also have a branch name master, but that's their name. If your name is Paul or Sarah or Jin or Kimi or whatever, and someone else has the same name, that's not the same person. If someone else's repository has a master, that's not the same branch (whatever that is), it's just spelled the same.
A series of commits, ending with a particular distinguished commit, which we call the tip commit of that series. We can choose to call this a branch, and many people do so, but to work with those commits, you must have the commits in your own Git repository. This means they're local, not remote.
So even a remote-tracking name is local: it's your own Git repository's memory of some other Git repository's branch name. That's what the catch phrase, "everything is local", is about. (This phrase turns up randomly on git-scm.com as you load various pages, so you might not see it right away.)
Now I want to merge these branches(which are remote) from Visual Studio Code ...
Some people really like IDEs. I'm not one of them. I, and others here, would encourage you to try out git-bash—a port of the bash Unix/Linux CLI to Windows, included with Git-for-Windows. There are a lot of reasons for this, but many of them boil down to the idea that Git is not a polished solution that does exactly one thing extremely well, and nothing else at all. Instead, Git is a collection of tools, each of which does one thing (with luck, doing it well, although some Git tools are sharper than others). When you put the whole collection of tools together into a workshop of sorts, you get something far more flexible and useful than a single polished solution. If you need to crank out 100 million widgets a day and do nothing else, you want a Widget Maker Mark 500, but you can't use that to fix the toilet seat and re-attach the car's rear-view mirror; the tool set can do both of those.
[
git status] says:On branch feature Your branch is up to date with 'origin/feature'. Changes not staged for commit:> (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: lib/Counterpage.dart modified: lib/main.dart no changes added to commit (use "git add" and/or "git commit -a")
If you use the CLI, your next step(s) include running git add:
git add lib/Counterpart.dart
git add lib/main.dart
or just:
git add -u
(which means add all updated files, i.e., everything that just got listed as not staged for commit).
You can, if you like, run:
git diff
first to view the stuff that's "not staged for commit" as a set of changes. Git doesn't store changes—Git stores snapshots, with every commit holding a full snapshot of every file—but the "show me what changed" tool is a good, sharp, useful tool with only a few dozen oddities to learn. (Most Git tools have weird knobs and handles sticking out at funny angles that do something extra when you use them, and some of these tools are pretty dull and liable to gouge off some skin or whatever, but git diff isn't bad this way.)
Having run git add, a git status will now list these files as having changes to be committed. You can now run:
git commit
to create, in your own repository, a new commit. This new commit will be found through your branch-name feature, on your feature branch. That's not the same as their feature, which your Git remembers as your origin/feature.
Once you have this new commit, you can send the commit to GitHub, to their feature, for instance:
git push
and you can then raise a GitHub "pull request" (PR) that asks someone else to inspect and/or take your new commit(s) into their master. At this point there's just the one commit, and you've sent it to GitHub so that GitHub have the new commit, and remember it as the latest commit on their feature, so your feature and their feature—which your software is calling origin/feature in your repository—are synchronized again.
You, or they, can then use some of the clicky web buttons on the GitHub web interface to merge that commit to master over on GitHub. Or, you can download the github-cli gh command, which lets you do this sort of thing from your bash prompt, by sending GitHub API requests. All of this lies outside Git proper: this uses GitHub add-ons. GitHub adds on a lot, because while Git is a pretty OK version control system, it has a complete lack of access control: anyone who can access your machine can do anything that can be done, as far as Git is concerned. Usually you want some kind of control over who can do what to the GitHub copy of the repository.
