I noticed that, on Windows, when I create a new branch in my repository using the shell, Git doesn't change the branch I am on. When using Linux, it does. How's that? Is there a possibility to change that, to the way Git in Linux does? (I'm very new to Git.)
To create a new branch and switch to it at the same time, use git checkout -b <branchname>.
I noticed that, on Windows, when I create a new branch in my repository using the shell, Git doesn't change the branch I am on
The commands for branching are the following:
# create branch and stay on the current branch
git branch <branch name>
# create a branch and switch to the new branch
git checkout -b <branch name>
# You can always create branch from any given commit/tag/branch etc you need
git checkout -b <SHA-1>/tag/branch
You can find in this answer a very useful information what it does and how to do it:
How to move HEAD back to a previous location? (Detached head)
Related
Branch "abcd/child" is created from "abcd/master" . Changes are made to "abcd/child" and meanwhile "abcd/master" also have added changes. Now how to make sure the latest changes are pulled from "abcd/master" is available in "abcd/child" using git commands in git bash?
Assuming abcd is the name of your remote, here's how I'd do it:
git checkout child
git pull
git merge abcd/master
git push
When you checkout child, it'll probably say "set up to track remote abcd" or similar.
The git pull command does two things: It fetches all updates from the server (on all branches) to your local git repo, and it updates your branch to match what's on the remote.
The git merge abcd\master means to specifically bring in all of the commits that are on the remote's copy of the master branch. That's important because you may not have updated your local master to have all those commits.
Note also that you might get conflicts in the git merge if both abcd and master have edited the same sections of the same file. There's lots of help in resolving git merge conflicts.
Also: You want to make sure everything works after the merge. It's possible that the changes on master broke an API that you were using, so you may need to make edits to deal with that.
Update: My assumption about abcd being the name of the remote is wrong.
First, get the name of your remote with the git remote command. Mine goes like this.
git remote
origin
So I only have one remote, and I call it origin. That's pretty common. If you've got more than one remote, it'll be trickier.
So, with "origin" as the remote it goes like this:
git checkout abcd/child
git pull
git merge origin/abcd/master
git push
Obviously substitute the name of your remote if it's not origin.
Same caveats apply about conflicts and making sure it works.
I need to extend a given tool with a Bash script that is supposed to work with Linux and MacOS. The script gets 2 parameters:
A repository location (file system, ssh, http(s), ...)
A commitish, e.g. branch, tag, commit hash
I have no influence on the parameters
The result of the script's run should be that
the repository is cloned to a fixed destination (always the same for one repository)
the repositorie's working tree should correspond to the latest state of the comittish (e.g. if it was a branch the tip of that branch)
If the repository does not (yet) exist locally, the procedure is as simple as
git clone $REPO_SOURCE $REPO_DIR
cd $REPO_DIR
git checkout $REPO_REF
My question: Consider a repository is already cloned to /repos/foo. After an obvios git fetch, how to I update that repository to the provided $REPO_REF?
If $REPO_REF was a branch, a git checkout $REPO_REF && git pull should work
If it was a commit hash, there was no update needed (just git checkout $REPO_REF?)
If it was a tag, then the tag might have been moved on the origin, how to handle this?
How to handle other edge cases?
Is there a simple reset-repository-to-this-commitsh way, so the repository behaves just as if it was freshly cloned?
Side nodes:
The same repository might be used with different commitish's, but only sequentially: It is guaranteed that the script isn't invoked more than once at the same time
All external changes to the repository might be always discarded without notification
While deleting and cloning the repository would work, it is impractical due to their sizes and it being an ugly solution
No (git) changes are needed, so checking out a detached head is okay
The only totally-foolproof yet convenient way is to have the other Git (the one you might be cloning, but might not) resolve the name for you. Then you have a hash ID and a hash ID is universal.
If the name is a branch or tag name, you can use git ls-remote to achieve that step. If it might be some other formulation (e.g., master~13) you're out of luck here. So, if you need to resolve the name locally:
If tag discipline is obeyed, no tag will ever move. This means that if you have an existing clone that has the tag, it has the right tag, and you're OK here, and if you have an existing clone that doesn't have the tag, you can add the tag and resolve it.
If tag discipline is not obeyed, you'd have to delete and re-create the tags (yuck), or else re-invent remote tags: copy their refs/tags/* names to your refs/rtags/<remote>/* name-space. See Git - Checkout a remote tag when two remotes have the same tag name.
If you have a branch name or something relative to a branch name, turn the branch name into your own remote-tracking name (e.g., replace master~13 with refs/remotes/origin/master~13) and resolve it.
In any case, you now have a hash ID and can use detached HEAD mode.
Using a "standard" git clone you could to this:
# cleanup old cruft
git reset --hard HEAD
git clean -fdx
# detach from current branch (if on any)
git checkout --detach
# delete all local branches
git for-each-ref --format="%(refname:strip=2)" refs/heads |xargs -r git branch -D
# fetch and update all remote refs and tags
git fetch --force --all --tags --prune --prune-tags
# checkout
git checkout "$COMMITISH"
That way you can rely on git checkout to do its job as usual and you don't need to replicate any of its heuristics, shortcuts etc.
Related to git - how to get default branch?
I'm trying to port a Bash script to Ruby. The script uses git symbolic-ref --short HEAD to get a repo's default branch.
Is there a way to combine rugged's repo.branches.each_name(:local) with some other command to find the default branch?
Or am I thinking too complicated and there is a useful default in rugged that I am missing? The script needs to continue by creating a new branch off the default/latest one, check-it out, commit something standardized, push the new branch, and open a pull request against that base branch.
I'm new to git and I started making changes to a previous commit without creating a new branch. (oops)
Now my local version is no longer the current master. Trying to push the changes gives me the following error: "The current branch could not be determined." If I check out the current master, I can commit as normal, but I lose all the changes I made after the mistake (but save in a backup local copy).
How do I push my new changes without checking out the current master? (branch, merge, etc.)
Or how do I connect my existing project to a new repository and start over?
(I tried changing the repository location to a new url, but I still have to check out the master to push..)
If the answer requires terminal commands, baby steps would be appreciated.
Here is the simple solution I use always - when I start developing on the master branch and forget to create new branch.
1. git stash
2. git checkout -b new-branch-name
3. git stash apply
4. git add *
5. git commit -m "commit"
6. git push origin new-branch-name .
That's all :)
Also as you are beginner you should play and learn git by playing this game and you will solve your problems related git by yourself :)
I created a new branch from my windows command box from the devdesktop application. but when I got to git bash and try to find this branch it doesn't exist. What can I do to sync what I see in git bash with what I created?
Choose one of below commands:
(1) Display latest branch with timestamp:
git for-each-ref --sort='-authordate:iso8601' --format=' %(authordate:relative)%09%(refname:short)' refs/heads
(2) List all branches at remote and local:
git branch
(3) List all branches, order by commit time desc, you will see lasted touched branch:
git branch --sort=-committerdate
(If order in ASC, git branch --sort=committerdate)
I was in another repository which had the same directory structure but was on a separate drive.