agis / git-style-guide Goto Github PK

  - Typically a hyphen or asterisk is used for the bullet,
    preceded by a single space, with blank lines in
    between, but conventions vary here

In your example, the hyphen is preceded by two spaces.

In the guide you have given following example for links:

Source http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Is it recommended to use : after source as:

Source: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

and also use Link instead of source?

ex:

Link: www.google.com

Hi, I'd like to create a pt-br version. What do you think about create another .md file like "style-guide-pt-BR.md"?

Hello have doubt regarding git rebase .

I have two branches one main and another my feature branch .

I made 3 commit on feature branch at 1pm 2pm and 3pm respectively, now I did the 4th commit on main-dev at 4pm , When I am on feature branch and running git rebase main , on top of 4th commit my 3 commits are there absolutely as expected , but here comes the problem as soon as I am running git push my feature branch is getting diverged and then getting merged into feature again .

Can you help here , why it is happening.

Below screenshot for reference

Hi!

I've translated the guide to Japanese. My japanese version of the guide is https://github.com/objectx/git-style-guide

It seems to be a pattern with branch names in this guide, but is it a good rule to make sure that branch names stay lowercase for the most part? If so, it should probably be written.

At this point, I'm polling the community before making a pull request.

Current style guide defines a 50-character limit for commits (and explicitly states that bad grammar should be used:

The commit summary line should be descriptive yet succinct. It should be no longer than 50 characters. It should be capitalized and written in imperative present tense. If it is a single sentence, do not put a period at the end:

1. 50-character limit is quite non-standard, the current standard being 70-75. This is even used for linux (source (note that this guideline is actually even used by the author of git). If there's a sane reason to define 50 as a new maximum, that reason needs to be clearly stated.
2. There's no sane reason to explicitly suggest bad grammar (omit the period). If the suggestion is to avoid proper grammar, a very good reason should accompany it (why should users follow a random guideline which suggests going against standards?).

I'm not necessarily suggesting that these two points be removed: but if the intentions is to keep them (and go against pre-existing standards), a sane reason should accompany them.

In my opinion, it's perfectly fine to have a messy local copy, and clean it up later on:

In particular, this applies to the "Commits" section, and the "Messages" section. It's perfectly reasonable to use local commits as temporary snapshots of your work, fixing a bug and implementing a feature simultaneously; it's only important that you rewrite history before pushing - in this case to two simple commits, one for the bugfix and one for the feature (if they can indeed be logically separate).

This is in no way meant to detract from the "do not rewrite published history" rule.

Thank you feedback from PR a few day ago.
I do translate again.

Korean version link is ( https://github.com/ikaruce/git-style-guide ).
Check my repo and add link to your repository.
Thank you.

Actually we can use the terminal to write multiline commit message by just not closing the double quotes and hitting any number of new lines as you like and close it with the double quotes.

I think semantic commits would be great to enforce:

http://seesparkbox.com/foundry/semantic_commit_messages

Hi @agis-,

This is some nice stuff here.

In the Commit Messages section, what do you think about having something to auto-format git commit messages that people can use in their choice of editors like Vim or Emacs etc.

I use Vim for my things so I have a separate auto command to wrap messages in 72 characters per line and for spell check also.

I thought asking you would be right before a pull request as I saw in another issue that you were talking about keeping only git related things in the guide not editor specific.

Sorry. Don't look at this!

I sent to you pull request.

Hey! I think people are routinely confused by vim because it appears to do nothing after you've written something. You may want to clarify the messages section to note what happens after you've written the description of a commit. i.e. now press :q to quit vim, etc.

I think it is a very good guide for me to manage my team.
Now I translate it into Chinese, and I want to know how to
merge into your repo.