Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 309 views

    Git Dos and Don'Ts: Hints and Common Pitfalls Matthias Männich, July 19 2011

    Uploaded by

    puja_malh
    This document provides 10 hints for using Git including: 1. Use separate local branches for isolated changes and name branches descriptively. 2. When switching work between branches, checkout a new branch rather than changing an existing one. 3. Do not switch branches during builds to avoid changing the working directory. 4. Merge public branches for integration and rebase local unpublished changes. 5. Rebasing public commits can cause issues, so avoid rebasing anything already merged or public. 6. Use reflogs and branches as markers to recover from unintended situations. 7. When cherry-picking, avoid cross-branch picks of public commits and push single commits. 8. Fetch and rebase before pushing to

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    Git Dos and Don'Ts: Hints and Common Pitfalls Matthias Männich, July 19 2011

    Uploaded by

    puja_malh
    309 views21 pages
    This document provides 10 hints for using Git including: 1. Use separate local branches for isolated changes and name branches descriptively. 2. When switching work between branches, checkout a new branch rather than changing an existing one. 3. Do not switch branches during builds to avoid changing the working directory. 4. Merge public branches for integration and rebase local unpublished changes. 5. Rebasing public commits can cause issues, so avoid rebasing anything already merged or public. 6. Use reflogs and branches as markers to recover from unintended situations. 7. When cherry-picking, avoid cross-branch picks of public commits and push single commits. 8. Fetch and rebase before pushing to

    Original Description:

    Git Dos Donts

    Original Title

    Git Dos Donts

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document provides 10 hints for using Git including: 1. Use separate local branches for isolated changes and name branches descriptively. 2. When switching work between branches, checkout a new branch rather than changing an existing one. 3. Do not switch branches during builds to avoid changing the working directory. 4. Merge public branches for integration and rebase local unpublished changes. 5. Rebasing public commits can cause issues, so avoid rebasing anything already merged or public. 6. Use reflogs and branches as markers to recover from unintended situations. 7. When cherry-picking, avoid cross-branch picks of public commits and push single commits. 8. Fetch and rebase before pushing to

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    309 views21 pages

    Git Dos and Don'Ts: Hints and Common Pitfalls Matthias Männich, July 19 2011

    Uploaded by

    puja_malh
    This document provides 10 hints for using Git including: 1. Use separate local branches for isolated changes and name branches descriptively. 2. When switching work between branches, checkout a new branch rather than changing an existing one. 3. Do not switch branches during builds to avoid changing the working directory. 4. Merge public branches for integration and rebase local unpublished changes. 5. Rebasing public commits can cause issues, so avoid rebasing anything already merged or public. 6. Use reflogs and branches as markers to recover from unintended situations. 7. When cherry-picking, avoid cross-branch picks of public commits and push single commits. 8. Fetch and rebase before pushing to

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    You are on page 1of 21

    Git

    DOs and DONTs


    Hints and Common Pitfalls
    Matthias Mnnich, July 19th
    2011

    Hint 1:
    Separate Local Branches
    recommended: One Change, One
    Branch
    easy checkout your isolated changes
    amend / rebase if necessary and push again

    delete branches that got obsolete


    fetch fresh branch information
    branches can be deleted with d if commits
    are public

    Hint 1:
    Separate Local Branches
    name your branches to remember
    the source and the intention
    mergeHana
    ISCrashFix_f4d
    B1234_hana

    Hint 2:
    Switching the target branch
    you intended to work on feature1 for
    hana
    => branch : feature1_hana

    now it should go to orange


    git checkout b feature1_orange
    origin/orange

    git log feature1_hana to get the


    hash(es)
    git cherry-pick <hash>

    Hint 3:
    Do not switch branches during build!
    switching branches with checkout
    changes working directory
    use hdbenvinit to set up a second
    workspace
    e.g. for git only tasks

    Hint 4:
    When to merge, when to rebase?
    Merge public branches for integrations
    done by topic owners

    $
    $
    $
    $

    git fetch
    git checkout b mergeIntoHana origin/hana
    git merge --no-ff --no-commit origin/dev
    git commit
    - adjust the commit message

    Do not rebase merge commits.


    Always begin with the first command to redo a merge.

    Hint 4:
    When to merge, when to rebase?
    Rebase local branches containing
    YOUR UNPUBLISHED changes H feature
    -1

    $ git checkout b feature-1


    origin/test
    origin/te
    $ hack hack hack
    st
    $ git commit
    $ git fetch
    $ git rebase origin/test

    G
    1

    F
    2

    C
    B
    A

    E
    1

    feature
    -1

    Hint 4:
    When to merge, when to rebase?
    Unpublished means:
    not yet merged to any public branch

    Your means:
    your local changes that come up in your
    history
    if you think this is always obvious, wait
    for the next slide

    Hint 5:
    What is a rebase of public commits?
    What exactly does a rebase?
    $ git checkout mybranch
    $ git rebase origin/dev
    Go to the latest commit in origin/dev
    Put on top everything that mybranch has,
    but origin/dev doesnt

    Right questions: What exactly gets


    rebased?

    Hint 5:
    What is a rebase of public commits?
    Simple case:
    mybranch has been based on origin/dev
    -> OK
    origin/d
    ev

    B
    A

    mybran
    ch

    Hint 5:
    What is a rebase of public commits?
    First bad case:
    mybranch has been based on origin/fixes-for-dev
    D

    mybran
    ch

    C
    origin/d
    ev

    origin/fixes-fordev

    B is rebased on origin/dev but is already public

    Hint 5:
    What is a rebase of public commits?
    Second bad case : Rebase after merge
    mybran
    ch

    D
    B

    origin/d
    ev

    origin/fixes-fordev

    C
    A

    simplified graph
    B is again put on dev (but B is already public on
    f4d)

    Hint 6:
    Recover from unintended situations
    use local branches as markers
    if you are not sure about the upcoming
    operation
    git branch save_me

    to easily get back to states


    mark important commits

    Hint 6:
    Recover from unintended situations
    git reflog: history of your local actions e.g.
    with commit hashes
    fc2180e HEAD@{0}:
    checkout: moving from secondbranch to master
    28e2275 HEAD@{1}:
    commit: second commit
    fc2180e HEAD@{2}:
    checkout: moving from master to secondbranch

    Hint 6:
    Recover from unintended situations
    git reflog g <branch>
    history of local actions for a certain local
    branch

    Hint 6:
    Recover from unintended situations
    If you think you did something wrong
    1. save console log to have the command history and
    output
    2. find important commits (gitk / reflog / cons. log)
    3. mark important commits
    4. temporary commit dirty files
    5. think about the next actions
    6. in most situations a fresh branch and cherry-picking
    your marked local commits is the most efficient way

    This usually only takes some minutes.

    Hint 7:
    Cherry-Picking done right
    Avoid cross-branch cherry-picking of
    public commits
    Potential conflicts have to be solved
    upstream
    Only push one commit when doing
    local cherry picking
    not the original one AND the picked one

    Hint 8:
    Getting your changes in quickly
    fetch and rebase before push
    this reduces the merge path
    avoids conflicts while merging in
    changes

    use commands provided by Gerrit


    Webinterface (checkout, cherry-pick)
    build and test locally before pushing

    Hint 9:
    What is local, what is remote?
    remote (porcelain) commands:
    clone
    fetch
    push
    pull

    local (porcelain) commands:


    everything else (commit, add, rebase,
    merge, status, checkout, )

    Hint 10:
    Do not use pull!
    Pull is
    fetch and merge

    If you rebase afterwards:


    potential rebase of public commits

    Just dont use it in our infrastructure

    Q&A

    You might also like