1. Learn Git
    1. Learn Git with Bitbucket Cloud
      1. Create a Git repository
      2. Copy your Git repository and add files
      3. Pull changes from your Git repository on Bitbucket Cloud
      4. Use a Git branch to merge a file
    2. Learn about code review in Bitbucket Cloud
      1. Fork a teammate's repository
      2. Copy your fork and make a change to the repository
      3. Create a pull request
  2. Getting Started
    1. What is version control
      1. Benefits of version control
    2. What is Git
      1. Performance
      2. Security
      3. Flexibility
      4. Version control with Git
    3. Why Git for your organization
      1. Git for developers
      2. Git for marketing
      3. Git for product management
      4. Git for designers
      5. Git for customer support
      6. Git for human resources
      7. Git for anyone managing a budget
    4. Install Git
      1. Install Git on Mac OS X
      2. Install Git on Windows
      3. Install Git on Linux
    5. Setting up a repository
      1. git init
      2. git clone
      3. git config
    6. Saving changes
      1. git add
      2. git commit
    7. Git Stash
      1. .gitignore
        1. Inspecting a repository
          1. git status
          2. git log
        2. Viewing old commits
          1. Undoing Changes
            1. git checkout
            2. git revert
            3. git reset
            4. git clean
          2. Rewriting history
            1. git commit --amend
            2. git rebase
            3. git rebase -i
            4. git reflog
        3. Collaborating
          1. Syncing
            1. git remote
            2. git fetch
            3. git pull
            4. git push
          2. Making a Pull Request
            1. How it works
            2. Example
            3. Where to go from here
          3. Using Branches
            1. git branch
            2. git checkout
            3. git merge
          4. Comparing Workflows
            1. Centralized Workflow
            2. Feature Branch Workflow
            3. Gitflow Workflow
            4. Forking Workflow
        4. Migrating to Git
          1. SVN to Git - prepping for the migration
            1. For administrators
            2. Basic Git commands
            3. Git Migration Tools
            4. For developers
          2. Migrate to Git from SVN
            1. Prepare
              1. Convert
                1. Synchronize
                  1. Share
                    1. Migrate
                      1. Perforce to Git - why to make the move
                        1. Migrating from Perforce to Git
                        2. Advanced Tips
                          1. Advanced Git Tutorials
                            1. Merging vs. Rebasing
                              1. Conceptual Overview
                              2. The Golden Rule of Rebasing
                              3. Workflow Walkthrough
                              4. Summary
                            2. Reset, Checkout, and Revert
                              1. Commit-level Operation
                              2. File-level Operations
                              3. Summary
                            3. Advanced Git log
                              1. Formatting Log Output
                              2. Filtering the Commit History
                              3. Summary
                            4. Git Hooks
                              1. Conceptual Overview
                              2. Local Hooks
                              3. Server-side Hooks
                              4. Summary
                            5. Refs and the Reflog
                              1. Hashes
                              2. Refs
                              3. Packed Refs
                              4. Special Refs
                              5. Refspecs
                              6. Relative Refs
                              7. The Reflog
                              8. Summary
                            6. Git LFS

                            Git Forks And Upstreams: How-to and a cool tip

                            Nicola PaolucciNicola Paolucci
                            Back to list

                            There are tons and then some useful guides on how to keep your forks updated against the upstream repositories (and if you're wondering why you would want to use forks in an enterprise setting, check out a few reasons here). In this blog I will introduce you to few aspects of how forking interacts with upstream: the basics, the gotcha's, and an cool tip. To top it off I will then make you very jealous, or very eager, the choice is yours. Interested? Read on.

                            The base workflow to keep up-to-date and contribute

                            Let me start by detailing a common setup and the most basic workflow to interact with upstream repositories.

                            In a standard setup you generally have an origin and an upstream remote - the latter being the gatekeeper of the project or the source of truth to which you wish to contribute to.

                            First, verify that you have already setup a remote for the upstream repository - and hopefully an origin too:

                            git remote -v
                            origin  git@bitbucket.org:my-user/some-project.git (fetch)
                            origin  git@bitbucket.org:my-user/some-project.git (push)

                            If you don't have an upstream you can add it simply with the remote command:

                            git remote add upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git

                            Verify that the remote is added correctly:

                            git remote -v
                            origin    git@bitbucket.org:my-user/some-project.git (fetch)
                            origin    git@bitbucket.org:my-user/some-project.git (push)
                            upstream  git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (fetch)
                            upstream  git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (push)

                            Now you can collect the latest changes of the upstream repository with fetch (repeat this every time you want to get updates):

                            git fetch upstream

                            (If the project has tags that have not merged to master you should also do: git fetch upstream --tags)

                            Generally you want to keep your local master branch as a close mirror of the upstream master and execute any work in feature branches (that might become pull requests later).

                            At this point it does not matter if you use merge or rebase, the result will typically be the same. Let's use merge:

                            git checkout master
                            git merge upstream/master

                            When you want to share some work with the upstream maintainers you branch off master, create a feature branch and when you're satisfied you push it to your remote repository.

                            You can also use rebase instead then merge to make sure the upstream has a clean set of commits (ideally one) to evaluate:

                            git checkout -b feature-x
                            #some work and some commits happen
                            #some time passes
                            git fetch upstream
                            git rebase upstream/master

                            If you need to squash a few commits into one you can use the awesome rebase interactive at this point.

                            After the above, publish your work in your remote fork with a simple push:

                            git push origin feature-x

                            A slight problem rises if you have to update your remote branch feature-x after you published it, because of some feedback from the upstream maintainers. You have a few options:

                            • Create a new branch altogether with the updates from you and the upstream.
                            • merge the updates from upstream in your local branch which will record a merge commit. This will clutter the upstream repository.
                            • Rebase your local branch on top of the updates from upstream and do a force push onto your remote branch:
                            git push -f origin feature-x

                            Personally I prefer to keep the history as clean as possible and go for option three, but different teams have different work flows. OBVIOUS ALERT!! You should do this only when working with your own fork. Rewriting history of shared repositories and branches is something you should NEVER do.

                            Tip of the day: Ahead/Behind numbers in the prompt

                            After a fetch, git status shows you how many commits you are ahead or behind of the remote the branch it syncs to. Wouldn't it be nice if you could see this information at your faithful command prompt? I thought so too so I started tapping with my bash chopsticks and cooked it up.

                            Here is how it will look on your prompt once you configure it:


                            And this is what you need to add to your .bashrc or equivalent, just a single function:

                            function ahead_behind {
                                curr_branch=$(git rev-parse --abbrev-ref HEAD);
                                curr_remote=$(git config branch.$curr_branch.remote);
                                curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);
                                git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';

                            You can enrich your bash prompt with this new function ahead_behind to have the desired effect. I leave the colorization as an exercise for the reader (not to clutter the tip too much).

                            Sample prompt:

                            export PS1="\h:\w[\$(ahead_behind)]$"

                            Inner workings

                            For those who like details and explanations here is how it works:

                            We get the symbolic name for the current HEAD i.e. the current branch:

                            curr_branch=$(git rev-parse --abbrev-ref HEAD);

                            We get the remote that the current branch is pointing to:

                            curr_remote=$(git config branch.$curr_branch.remote);

                            We get the branch onto which this remote should be merged to (with a cheap Unix trick to discard everything up to and including the last forward slash /):

                            curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);

                            Now we have what we need to collect the counts for the commits we are ahead or behind:

                            git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';

                            We use the age old Unix tr to convert the TAB to a separator |.


                            I hope this basic walk-through on upstream is useful for those unfamiliar with the process. Also note that the latest uber-fresh Bitbucket Server release includes fork synchronization which basically relieves the developer from all the burden of keeping up to date with its forks, check it out!

                            Follow me @durdn and the awesome @AtlDevtools team for more DVCS rocking.