Before we get started

  • We’ve selected the bitbucket remote repository to document our git workflows. Other remote repositories include github and UD’s SHUEBox.
  • The git command line clients below use a Bash shell running in the Windows’ cmd, powershell, or mysys loaded with standard linux commands and use linux filesystem convention (though directory names remain the same)
  • Brackets below, in the form “[somevariable]”, indicate a user-defined variable

#1 Simple/Single developer

    1. Create a Bitbucket account at https://bitbucket.org/ use your udel.edu email address for features granted to educational accounts.
    2. Create “test” repository on Bitbucket.  You’ll need to create your account first

  1. On the “Repository Setup” screen expand the “I’m starting from scratch” section.  We’ll be coming back to this
  2. Proceed on either a Graphical (GUI) or a command line client.  You may want to use a GUI client if you are new to git or to working in a command line environment.
    1. Using a GUI
      1. Download a git GUI client (http://windows.github.com/, http://mac.github.com/, or http://www.sourcetreeapp.com/).  Instructions below are for the github GUI client.  This also comes with a bundled command line client, which you can use to untangle issues where the GUI is limited.
      2. Follow these instructions to setup your client
    2. Using a command-line client
      1. Download the git client from http://git-scm.com/downloads … this will either run in an included Bash shell or in the shell already on your system
      2. Start the git shell appropriate for your system.  On Windows this is under Start > All Programs > Git > Git Bash
      3. Do you have .ssh keys?  You can see if they exist by running $ ls –al ~/.ssh, do you see a file ending in _rsa.pub?
        1. Yes?
          1. Copy and paste this text from this public key (e.g., ~/.ssh/id_rsa.pub) on bitbucket.com under your profile (https://bitbucket.org/[user]) > Manage account > SSH keys > Add key
        2. No?
          1. Run the following in your git Bash/shell
            1. ssh-keygen (and follow defaolts)
            2. cat ~/.ssh/id_rsa.pub (whatever the name of the .pub file is)
            3. copy and paste this text on bitbucket.com under your profile (https://bitbucket.org/[user]) > Manage account > SSH keys > Add key
      4. Follow the remainder of “I’m starting from scratch” to create git support files in the directory where your code will be stored; to point to your remote git location; and to create and push an initial commit.  For example:
        1. mkdir /path/to/your/project
        2. cd /path/to/your/project
        3. git init
        4. git remote add origin git@bitbucket.org:[user]/test.git
        5. echo “User” >> contributors.txt
        6. git add contributors.txt
        7. git commit -m ‘Initial commit with contributors’
        8. git push -u origin master
      5. Use the following git command workflow after you’ve changed files
        1. git status (useful to see what’s changed)
          1. You may want to run git whatschanged or git diff to see more details
          2. You  may want to run git add to add files under your project directory that are not yet tracked by git
        2. git –am “some message”  I use the –am switch to avoid needing to separate “stage” my files
        3. git push this will push to the remote repository (bitbucket) set up in a previous step

#2 Development/Production deployment

  1. Create a branch, let’s call it “dev”, via bitbucket.com (you could also do this via a GUI client or shell, but these instructions assume via bitbucket)
  2. Clone the remote repository into a new [project-dev] directory, where “project” is the name of your project (e.g., for project udeploy woold be udeploy-dev)
  3. git clone git@bitbucket.org:[user]/[project].git [project-dev]
  4. Checkout the dev branch, locally, using the GUI or shell git client (git checkout dev)Git Workflows Bitbucket Collaborative from git Workflows hosted by UD Capture
  5. Modify some code.  Run git commit -am “some message” to commit changes to this branch
  6. Test changes on this branch (e.g., http://localhost/project-dev)
  7. Merge changes to master branch
    1. git checkout master
    2. git merge dev
  8. Push all changes to remote repository, making sure to track all branches git push –all origin -u
  9. Add changes to production filesystem location
    1. cd ../project
    2. git pull

Optional You can include path specific dependencies by using include (or equivalent in your code) and creating an include file that you specific in a file called .gitignore

  1. echo ‘include.php’ > .gitignore

Git Workflows Bitbucket Gitignore from git Workflows hosted by UD Capture

#3 Contributions via cloud editor (Bitbucket)

  1. Provide read or write access for a group or individual to your repository.  Changes via write permissions are directly committed by those making them.  Changes via read permissions are made in an easily created “fork” which can be vetted and selectively merged by the repository “owner”.  In general you’ll want to balance code stability, giving that minimal “read” capability, and sustainability, giving enough “write” or “admin” access, so that others can assist in management tasks such as merging code and adding users.
    1. If you work with a group of developers who you trust to make unvetted changes to the code, you might want to create a group, and give this group ownership of the project.  This also has the benefit of sustainability, shoold a lead developer’s responsibilities shift.
    2. You coold create a group and, rather than make it owner, give it read or write permissions
    3. Finally you coold simply add individual users, giving them admin, read, or write permissions
  2. Changes for individuals with write permission
    1. Add the individual to your repository under the “Access management” tab.  They will need an existing bitbucket account
    2. They can now directly make changes to code under the “Source” tab, clicking on a file to view it, and then clicking “Edit” to edit it
    3. Editors can “View Diff” or differences, before they “Commit” their changes
    4. Editors can Commit the change directory or Create a poll request with an automatically created Branch with the change.  This is the best way to ensure code stability, with reviewers specified (and automatically notified).  After code is reviewed by the reviewers, they will have the option to merge the Branch (the changes) or simply Approve the changes, and the editor can then merge the Branch.
    5. Code will then need to polled to local repositories, such as the production location on the server.  To do this run git pull or Sync with a GUI client
Subscribe

Follow this blog

Get a weekly email of all new posts.