$30 off During Our Annual Pro Sale. View Details »

GIT - Good Practices

GIT - Good Practices

Krzysztof Wawer

September 09, 2017
Tweet

More Decks by Krzysztof Wawer

Other Decks in Programming

Transcript

  1. GIT - Good Practices
    Krzysztof Wawer
    ! @wafcio
    " [email protected]

    View Slide

  2. https://github.com/kamranahmedse/developer-roadmap

    View Slide

  3. View Slide

  4. More resources
    • https://book.git-scm.com/doc

    • https://book.git-scm.com/book - Pro Git

    View Slide

  5. 1. Git Config

    View Slide

  6. Basic Git Config
    $ git config --global user.name “Krzysztof Wawer”

    $ git config --global user.email “[email protected]
    $ git config --global user.name “Krzysztof Wawer”

    $ git config --global user.email “[email protected]

    View Slide

  7. Basic Git Config
    commit 889b29f9d9b81d146bd48f78a31bcc4f384690c0
    Author: Krzysztof Wawer

    Date: ….

    Show error message when quote is invalid



    commit 421fa0eb5d8ce772b2374fe379a608f1cd103372
    Author: Krzysztof Wawer

    Date: …

    Add Basket component


    View Slide

  8. Basic Git Config

    View Slide

  9. Basic Git Config
    $ git config --global user.name “Krzysztof Wawer”

    $ git config --global user.email “[email protected]
    $ git config user.email “[email protected]

    View Slide

  10. 2. .gitignore

    View Slide

  11. .gitignore

    View Slide

  12. .gitignore
    $ git config --global core.excludesfile ~/.gitignore

    View Slide

  13. 3. Do commit early
    and often

    View Slide

  14. Look good ?
    http://deadlock.org.ua/kit/habr/post/14736

    View Slide

  15. 4. Good Git Commit
    Message

    View Slide

  16. Git Commit Message
    1. Separate subject from body with a blank line

    2. Limit the subject line to 50 characters

    3. Capitalize the subject line

    4. Do not end the subject line with a period

    5. Use the imperative mood in the subject line

    6. Wrap the body at 72 characters

    7. Use the body to explain what and why vs. how
    https://chris.beams.io/posts/git-commit/

    View Slide

  17. Summarize changes in around 50 characters or less

    More detailed explanatory text, if necessary. Wrap it to about 72

    characters or so. In some contexts, the first line is treated as the

    subject of the commit and the rest of the text as the body. The

    blank line separating the summary from the body is critical (unless

    you omit the body entirely); various tools like `log`, `shortlog`

    and `rebase` can get confused if you run the two together.

    Explain the problem that this commit is solving. Focus on why you

    are making this change as opposed to how (the code explains that).

    Are there side effects or other unintuitive consequences of this

    change? Here's the place to explain them.

    Further paragraphs come after blank lines.

    - Bullet points are okay, too

    - Typically a hyphen or asterisk is used for the bullet, preceded

    by a single space, with blank lines in between, but conventions

    vary here

    If you use an issue tracker, put references to them at the bottom,

    like this:

    Resolves: #123

    See also: #456, #789
    https://chris.beams.io/posts/git-commit/

    View Slide

  18. 5. Do choose a
    workflow

    View Slide

  19. Feature Branches
    https://www.atlassian.com/git/tutorials/comparing-workflows

    View Slide

  20. Release Branches
    https://www.atlassian.com/git/tutorials/comparing-workflows

    View Slide

  21. Maintenance Branches
    https://www.atlassian.com/git/tutorials/comparing-workflows

    View Slide

  22. Git history
    https://paulcunningham.me/git-workflow-powershell-scripting/

    View Slide

  23. Git history
    http://www.bitsnbites.eu/a-tidy-linear-git-history/

    View Slide

  24. Linear git history
    Rebase commit(s) with parent branch
    $ git checkout master

    $ git pull

    $ git checkout my-branch

    $ git rebase master

    View Slide

  25. Thanks

    View Slide