Cloning a repository
$ git clone “http://example.com/repo.git”
Storing username and password
$ git config credential.helper store
$ git push http://example.com/repo.git
Username:
Password:
Undoing a git merge:
$ git reset –hard commit_sha
$ git reset –hard HEAD~x ;where x is the number of commits to back up to
Pulling just one file:
$ git fetch {remote}
$ git checkout FETCH_HEAD — {file}
file update exclusions:
$ git update-index –assume-unchanged {file}
scratch pad:
$ git-stash – Stash the changes in a dirty working directory away
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
Git undo strategies guide:
https://www.atlassian.com/git/tutorials/undoing-changes
https://opensource.com/article/18/6/git-reset-revert-rebase-commands
Branching:
Create a new branch
$git checkout -b “branch_name”
Pushing commits to a new branch
$git push -u origin “branch_name”
the -u flag ensures that you’re telling git that the remote repo will become the upstream source
Rename a local branch
git branch -m new-name (if currently on the branch to rename)
git branch -m old-name new-name (if currently on a different branch)
Delete the old-name remote branch and push the new-name local branch.
git push origin :old-name new-name
Reset the upstream branch for the new-name local branch.
git push origin -u new-name
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
https://stackoverflow.com/questions/17096311/why-do-i-need-to-explicitly-push-a-new-branch#17096880
Rename a local and remote branch in git
This is by far the simplest and most straightforward instruction on how to get a repository up an running in no time, put together by Karl Broman:
http://kbroman.org/github_tutorial/pages/init.html
Start a new git repository
Your first instinct, when you start to do something new, should be git init. You’re starting to write a new paper, you’re writing a bit of code to do a computer simulation, you’re mucking around with some new data … anything: think git init.
A new repo from scratch
Say you’ve just got some data from a collaborator and are about to start exploring it.
- Create a directory to contain the project.
- Go into the new directory.
- Type
git init. - Write some code.
- Type
git addto add the files (see the typical use page). - Type
git commit.
The first file to create (and add and commit) is probably a ReadMe file, either as plain text or with Markdown, describing the project.
Markdown allows you to add a bit of text markup, like hyperlinks, bold/italics, or to indicate code with a monospace font. Markdown is easily converted to html for viewing in a web browser, and GitHub will do this for you automatically.
A new repo from an existing project
Say you’ve got an existing project that you want to start tracking with git.
- Go into the directory containing the project.
- Type
git init. - Type
git addto add all of the relevant files. - You’ll probably want to create a
.gitignorefile right away, to indicate all of the files you don’t want to track. Usegit add .gitignore, too. - Type
git commit.
Connect it to github
You’ve now got a local git repository. You can use git locally, like that, if you want. But if you want the thing to have a home on github, do the following.
- Go to github.
- Log in to your account.
- Click the new repository button in the top-right. You’ll have an option there to initialize the repository with a README file, but I don’t.
- Click the “Create repository” button.
Now, follow the second set of instructions, “Push an existing repository…”
$ git remote add origin git@github.com:username/new_repo
$ git push -u origin master
Actually, the first line of the instructions will say
$ git remote add origin https://github.com/username/new_repo
But I use git@github.com:username/new_repo rather than https://github.com/username/new_repo, as the former is for use with ssh (if you set up ssh as I mentioned in “Your first time”, then you won’t have to type your password every time you push things to github). If you use the latter construction, you’ll have to type your github password every time you push to github.
Changing remote URL:
$ git remote set-url git@github.com:USERNAME/REPOSITORY.git
Check that the remote has been properly updated:
$ git remote -v
Push an existing Git repo
cd existing_repo
git remote rename origin old-origin
git remote add origin git@github.com:USERNAME/REPOSITORY.git
git push -u origin –all
git push -u origin –tags
Reverting to a previous commit.
git log or git log –oneline
:grab the appropriate commit hash from the printed log:
git checkout
So I ran into an issue: “HEAD detached from …”
I was no longer connected to the main branch I was working on. Arrgh!
So Stack Overflow gave the following solution to get back on track:
First, let’s clarify what HEAD is and what it means when it is detached.
HEAD is the symbolic name for the currently checked out commit. When HEAD is not detached (the “normal”1 situation: you have a branch checked out), HEAD actually points to a branch’s “ref” and the branch points to the commit. HEAD is thus “attached” to a branch. When you make a new commit, the branch that HEAD points to is updated to point to the new commit. HEAD follows automatically since it just points to the branch.
git symbolic-ref HEAD yields refs/heads/master
The branch named “master” is checked out.
git rev-parse refs/heads/master yield 17a02998078923f2d62811326d130de991d1a95a
That commit is the current tip or “head” of the master branch.
git rev-parse HEAD also yields 17a02998078923f2d62811326d130de991d1a95a
This is what it means to be a “symbolic ref”. It points to an object through some other reference.
(Symbolic refs were originally implemented as symbolic links, but later changed to plain files with extra interpretation so that they could be used on platforms that do not have symlinks.)
We have HEAD → refs/heads/master → 17a02998078923f2d62811326d130de991d1a95a
When HEAD is detached, it points directly to a commit—instead of indirectly pointing to one through a branch. You can think of a detached HEAD as being on an unnamed branch.
git symbolic-ref HEAD fails with fatal: ref HEAD is not a symbolic ref
git rev-parse HEAD yields 17a02998078923f2d62811326d130de991d1a95a
Since it is not a symbolic ref, it must point directly to the commit itself.
We have HEAD → 17a02998078923f2d62811326d130de991d1a95a
The important thing to remember with a detached HEAD is that if the commit it points to is otherwise unreferenced (no other ref can reach it), then it will become “dangling” when you checkout some other commit. Eventually, such dangling commits will be pruned through the garbage collection process (by default, they are kept for at least 2 weeks and may be kept longer by being referenced by HEAD’s reflog).
1 It is perfectly fine to do “normal” work with a detached HEAD, you just have to keep track of what you are doing to avoid having to fish dropped history out of the reflog.
The intermediate steps of an interactive rebase are done with a detached HEAD (partially to avoid polluting the active branch’s reflog). If you finish the full rebase operation, it will update your original branch with the cumulative result of the rebase operation and reattach HEAD to the original branch. My guess is that you never fully completed the rebase process; this will leave you with a detached HEAD pointing to the commit that was most recently processed by the rebase operation.
To recover from your situation, you should create a branch that points to the commit currently pointed to by your detached HEAD:
git branch temp
git checkout temp
(these two commands can be abbreviated as git checkout -b temp)
This will reattach your HEAD to the new temp branch.
Next, you should compare the current commit (and its history) with the normal branch on which you expected to be working:
git log –graph –decorate –pretty=oneline –abbrev-commit master origin/master temp
git diff master temp
git diff origin/master temp
(You will probably want to experiment with the log options: add -p, leave off –pretty=… to see the whole log message, etc.)
If your new temp branch looks good, you may want to update (e.g.) master to point to it:
git branch -f master temp
git checkout master
(these two commands can be abbreviated as git checkout -B master temp)
You can then delete the temporary branch:
git branch -d temp
Finally, you will probably want to push the reestablished history:
git push origin master
You may need to add –force to the end of this command to push if the remote branch can not be “fast-forwarded” to the new commit (i.e. you dropped, or rewrote some existing commit, or otherwise rewrote some bit of history).
If you were in the middle of a rebase operation you should probably clean it up. You can check whether a rebase was in process by looking for the directory .git/rebase-merge/. You can manually clean up the in-progress rebase by just deleting that directory (e.g. if you no longer remember the purpose and context of the active rebase operation). Usually you would use git rebase –abort, but that does some extra resetting that you probably want to avoid (it moves HEAD back to the original branch and resets it back to the original commit, which will undo some of the work we did above).
https://stackoverflow.com/questions/5772192/how-can-i-reconcile-detached-head-with-master-origin