-
list your local branches
git branch -avv -
clone using ssh
git clone ssh://[email protected]/home/user/work/test1 -
very frequently, a common mistake that is made is that you clone from each other and then you might push to the wrong repository. To make sure you are pushing to the right repository,
-
first make sure your remote urls are correct by running
git remote -vorigin http://[email protected]/abcd (fetch) origin http://[email protected]/abcd (push)
-
then do
git branch -a --contains 8a8abc4978c991d09a321ce692ac3366ea097051
(no branch) master remotes/origin/HEAD -> origin/master remotes/origin/master
-
-
git logshows you a long sha-1 hash commit-id (e.g. f2e9e8950fe0fa56de586d569959e741ba92e816). This hash is unique among all commits of all branches in a particular repository. The likelihood that this will clash is some absurdly low probability (the sun crashing into the earth or something). *if you want to see the commits/branches that this revision came from (its parents), dogit rev-list --parents --max-count=1 f2e9e8950fe0fa56de586d569959e741ba92e816 -
the correct way of pushing tags (and pushing in general) is
git push --tags -
Never do git pull, though everyone tells you. Always do a
git fetch -t(this makes sure you get the tags too) and then explicitly merge the remote branch with your local branch.
git fetch -t origin remote: Counting objects: 382, done. remote: Compressing objects: 100% (203/203), done. remote: Total 278 (delta 177), reused 103 (delta 59) Receiving objects: 100% (278/278), 4.89 MiB | 539 KiB/s, done. Resolving deltas: 100% (177/177), completed with 40 local objects. From http://[email protected]/aaa 3036acc..9eb5e40 branch1 -> origin/branch1 *[new branch] branch2 -> origin/branch2 *[new branch] some-dev -> origin/some-dev 3d619e7..6260626 master -> origin/master
-
Now, check the revisions that have been fetched
git log some-dev..origin/some-dev. This will show you all revisions that are in remote some-dev branch, but not in your local some-dev branch. -
after you are happy with incoming, do
git rebase origin/master masterORgit merge origin/master master. Using merge will create an extraneous merge commit. -
sometimes even when you do a fetch, you wont get all the revisions. Dunno why. In such cases, you need to do a
git fetch -t --all. -
The correct way of creating tags is the following
git tag -am "Tagging release 0.1.35" 0.1.35 fdb61c887fbf3ea59510416d8e487c0fce27fdad -
If you create tags that way, then devops can manage your tags much easier. For example, sort tags by tag date:
git for-each-ref --format="%(taggerdate): %(refname)" --sort=-taggerdate refs/tags -
Did you just delete your branch and your commits are lost ? dont panic, because in git nothing is lost. Your activity is captured in something called the reflog. You can see this by doing
git reflogorgit log --walk-reflogs master. Once you see the commits that you like, create a patch bygit show <commit-id> -
Important: git does some strange things that when you try to do a push, it pushes all branches rather than the branch you were working on. Fix this by
git config --global push.default upstream(or equivalent for your version of git) -
By default, git uses fast-forward while merging, i.e. applies my changes directly to the master branch if possible and forgets about my branch. Make sure you add the
merge.ff = falseflag to your.gitconfig- note that this breaks bisects (http://sandofsky.com/blog/git-workflow.html)
- there is a strong reason for the existence of fast-forward : http://stackoverflow.com/a/2850413/112050
-
Create a
~/.gitignorefile and fill it with the following content*.swp *.swo *~
- then run
git config --global core.excludesfile ~/.gitignore
- then run
git update-index --assume-unchanged <filename>
and the opposite git update-index --no-assume-unchanged <filename>