This looks like a set of notes that are mostly correct but encourage bad practices. I think it's because they author doesn't understand git and doesn't know what they are doing.
>A lightweight tag is simply a named pointer to a commit. You can always change it to point to another commit.
Umm, you can do this, but in general you should never rename tags. Occasionally a developer will tell me the tag they pushed is incorrect and I'll agree to remove it only if they promise not to re-create it. If you read the man page on git-tag it's clear why you should avoid doing this.
>A lovely little tip – don’t forget that branch names aren’t limited to a-z and 0-9. It can be quite nice to use / and . in names for fake namespacing
If you use '/' is branch names you can create path conflicts. I've seen it happen and it took me a day to debug and figure out. There is some code checking for path conflicts in the git source but it's not invoked via all code paths that create branches. I recommend against using slashes in branch names unless you know what you are doing.
"I think it's because they author doesn't understand git and doesn't know what they are doing."
Thanks for your kind comment...
I would like to point out that this article is over 4 years old (hence my knowledge will have increased since then) and it was also basically my notes on our training with Scott Chacon of GitHub. I'm sure you wouldn't consider him to not "know what [he is] doing". Maybe it reflected best practices at the time the training was delivered and the article was written.
Anyway, I appreciate it's resurgence in popularity...
>If you use '/' is branch names you can create path conflicts. I've seen it happen and it took me a day to debug and figure out. There is some code checking for path conflicts in the git source but it's not invoked via all code paths that create branches. I recommend against using slashes in branch names unless you know what you are doing.
Can you elaborate on this? What you said doesn't make much sense. If having a slash in the branch name creates path conflicts, that means slashes are treated specially, right? How exactly does someone 'know what they are doing' to be able to use them?
$ git branch fireos
$ git branch fireos/feature-branch
error: unable to create directory for .git/refs/heads/fireos/feature-branch
fatal: Failed to lock ref for update: No such file or directory
This happens because creating 'fireos' branch stores the sha1 in file .git/refs/heads/fireos. But if you later want to create branch 'fireos/feature-branch', git needs to store the sha1 in .git/refs/heads/fireos/feature-branch. This is impossible because 'fireos' is a file and cannot be a directory. Path conflict.
It can be solved with a right branch naming policy. E.g. where I work we usually name branches like "wp/BTS-number/1" for first attempt to do the BTS-number task, "wp/BTS-number/2" when we somehow need to try another approach or rebase or squash history, "wp/BTS-number/3" for next attempt and so on.
But its a global policy so "wp" and "wp/BTS-number" will always be a folder, and conflicts should never happen.
> Umm, you can do this, but in general you should never rename tags. Occasionally a developer will tell me the tag they pushed is incorrect and I'll agree to remove it only if they promise not to re-create it. If you read the man page on git-tag it's clear why you should avoid doing this.
I'll take your word for it, but the git man pages are notoriously unreadable. They might be useful for a git guru, but for someone that is learning the commands they are downright harmful.
> I'll take your word for it, but the git man pages are notoriously unreadable. They might be useful for a git guru, but for someone that is learning the commands they are downright harmful.
Can you elaborate? I'm definitely not a git guru and I always read the man pages, and I find them quite readable. It's also the first place I learn best practices from.
Sure. I think this is largely a matter of preferences in pedagogy, but when I'm looking to learn something, I like to have heavily annotated examples that get progressively more complex.
Listing every option with a description, to me, is not as useful as seeing it in practice.
We use slashes at our company as a manner of course, and we've had no issues. We name all our features as `feature/i18n` and our bug fixes as `hotfix/ie-promises`.
Of course, we might have issues if we named a branch `feature` or `hotfix`, but that's never been an issue for us.
The master tip: have a detailed written policy on git usage, on what goes into which branch, on git commit message format, and make really, really sure everyone understands it before they start anything.
At my current gig we use a set of git hooks, and the pre-commit hook enforces the git comment style, which performs integration with bugtracking/timetracking. We wrote our own and it's just a couple of regexes tied to a couple of warnings.
Look in any git project's .git/hooks/ directory for some sample scripts.
I've seen a project where the lead guy wrote two scripts he called "git-rebase-merge" and "git-lock". Imagine when you have the ability to lock and rebase merge commits. This leads to an endless stream of errors and head scratching.
I replied to an individual comment, but I would just like to comment generally too - this article is 4 years old and if I wrote the article now there would have been more advanced information.
At the time beginners in git weren't doing much of this stuff, so they were tips for people who had used git daily, but this stuff wasn't common knowledge being done by all developers.
If anyone has anything they'd like to see in an advanced article, let me know and maybe I'll consider writing a "Tips for becoming an Advanced Git User" :-)
Thanks! I'm intermediate in some parts of git and not on others, but since I'm a visual learner this layout really helps me see how the different commands relate to each other.
Agreed. I was expecting more substance in the hooks department, diffs, or other things off the beaten path. This just seems like a list of the basic git commands.
I find this hardly informative. Those users who consider themselves intermediate already know all this stuff. When I clicked the link I thought I will see about interactive rebasing, advanced stashing and stuff like that. There are other things which are already mentioned by others but the tag handling advice is horrible. Tags are meant to be immutable milestones. Never change them and please don't encourage people to do so.
I've found in practice that using "stash" is a very effective way to ensure you'll spend lots of time in the future looking for a lost branch. I don't like stash anymore.
I like the idea of aliasing the command unstage, but once "reset HEAD" is in the muscle memory its kinda stuck.
Is git-flow still cool? Or is it so popular its just assumed to be in use as a standard, thus well beneath the level of an "intermediate" users guide? If you don't use "the" git flow repo, at least as a branch naming strategy and overall usage strategy it's worked pretty well for me.
I am in a cafe and was sipping my coffee when I read your comment. Now people are looking at me laugh my ass off, with half the coffee spilled on the keyboard.
>A lightweight tag is simply a named pointer to a commit. You can always change it to point to another commit.
Umm, you can do this, but in general you should never rename tags. Occasionally a developer will tell me the tag they pushed is incorrect and I'll agree to remove it only if they promise not to re-create it. If you read the man page on git-tag it's clear why you should avoid doing this.
>A lovely little tip – don’t forget that branch names aren’t limited to a-z and 0-9. It can be quite nice to use / and . in names for fake namespacing
If you use '/' is branch names you can create path conflicts. I've seen it happen and it took me a day to debug and figure out. There is some code checking for path conflicts in the git source but it's not invoked via all code paths that create branches. I recommend against using slashes in branch names unless you know what you are doing.