Current Articles | RSS Feed RSS Feed

About Assembla Team Git

Posted by Andy Singleton on Wed, Feb 26, 2014
  
  
Tags: 

Assembla became known as the world's best Subversion host, but during the past four years we have added great Git workflows, and we rely on them for all of our own development.  This article answers some questions that we got recently about where to use Assembla Git, instead of Github or Gerrit or Bitbucket.  Please contact us if you need help getting started.

WHY USE ASSEMBLA?

Assembla is designed to build the “team” in distributed team.  Assembla gives you a team-oriented way to use git. You can put all of the branches and repositories in one workspace, with shared team permissions, one activity stream, and full visibility for new and existing team members.

Assembla is great if you create a lot of new projects, apps, and sites.  The "space" container increases maintainability by putting everything for a project in one place - code, documentation, tickets, history, team, FTP or SSH deploy, and extra tabs that can contain build and monitoring tools.  You get started quickly, you can always come back for enhancements, you never lose anything, and you can hand off to new team members and contractors, or make an extremely complete and professional delivery to clients.

FEATURES and WORKFLOWS

Assembla links code commits and merge requests to a ticket (or issue). You can see a complete history of the changes that affect a ticket.

You can ALSO see a list if the tickets that were affected by a merge request or a list of merges. This gives you automated release notes for a continuous delivery process.

Assembla implements the complete Github-style individual coding workflow. Developers can make an individual branch or repository. They can submit pull requests (called merge requests). They can review, comment, accept, or reject merges. They can use @mention and @mention! to call for reviews or post comments for specific team members.

Assembla also implements a Gerrit-style workflow which is often better for big teams or full-time teams. In the Gerrit-style workflow, team members start from a shared master branch, and they make temporary branches to review specific changes. This unifies the team and removes the work that team members have to do to maintain their own repositories. Assembla has automated this workflow to simplify the Gerrit or “branch per ticket” flow. The master branch can be marked as “protected”. When team members push changes to the master branch, Assembla automatically creates a temporary branch to test and review the change.

Assembla has a full API and Jenkins integration so that you can run continuous integration on review branches, merge requests, and master branches. Jenkins can even be added as an Assembla tab.

GETTING STARTED

If you already have an Assembla project and want to try our Git hosting, visit the Admin tab > Tools section of your project to instantly add a Git repository. If do not have an Assembla project, sign up for free now

0 Comments Click here to read comments

The Compare Report for Git & Subversion

Posted by Titas Norkunas on Thu, Sep 26, 2013
  
  

We have improved the Compare Report for Continuous Agile use cases. The Compare Report can be found via the "Compare" subtab of you repository. It can show you recent changes (for instance, changes that you just released), or it can show you changes between two branches or forks (for instance, changes that you want to submit for merge).

Continuous Use Cases

In continuous workflows it is very common to use the master branch as the "production" branch. Here are three common actions that we recently made very easy to accomplish.

See what was recently released

If you are using tags, it’s very easy to see what your team has recently released - just click on recent tags and you will see what your team has merged to master recently. If you want to see a more fine grained view, go to the commits tab and scroll through the commits to find the one you want.

See released tickets easily

Protip: Select the most recent tag to see if your team is really following your process and keeping master in production (if they are, there should be no changes).

See released tickets:

You will also see a subtab that links to the affected tickets list. This can be used as automated release notes that show you what actually got out. Our CEO Andy loves this feature.

 

Create merge request after seeing changes:

Simply select your branch and a new merge request button will appear. If you want to create a merge request against master, just click “Create Merge Request”, fill in description and send the request!

We hope you like our freshly improved compare report. Let us know in the comments!

0 Comments Click here to read comments

Using Codebox as a Web-Based Code Editor for Assembla

Posted by adam feber on Wed, Aug 28, 2013
  
  

Using Codebox to edit Assembla Git repositories online is really easy with their recent Assembla integration. You and your team members can simply work on a clone of your Assembla repository, test the code and then push back to Assembla. 

1. Sign up for FriendCo.de

You can easily sign up and log in with your Assembla account. 

friendcode 1

2. Import a Repository to Work On

Visit the repository settings page of your FriendCode account and select the 'Import' button for the repository you would like to import.

Note: If you already had a login to FriendCode and did not sign up via Assembla, you will have to connect your Assembla account on this page before you can import individual Assembla repositories. 

friendcode 2

After clicking 'Import', a modal will guide you through the import process. You can change the name, the description, and choose to import as a private repository. Note: You must not have any spaces in the name to successfully Fork. 

friendcode 3

3. Edit and Commit

FriendCode will now display the page of your newly imported repository, simply select the branch you want to work on (for exemple “master” or “dev”). You can also create new branches off other base branches.

friendcode 4

FriendCode has now created a full workspace for you to edit that branch : you can open files, edit them, save changes, and commit your changes.

friendcode 5

friendcode 6

4. Push to Assembla

When you are ready to push to Assembla, open the left panel and select the deployment solution “Push upstream” which will push your new commits to the original repository on Assembla.

friendcode 7

A logs tab will open to show you the result:

friendcode 8

And you will see the commit in your Assembla repository:

friendcode 9

Happy coding!

6 Comments Click here to read comments

Calling All Hackers - Automate Git and SVN Workflows, Get Assembla For Free!

Posted by Michael Chletsos and Titas Norkunas on Fri, Jun 28, 2013
  
  

A Contest for Hackers

Recently we released an exciting feature, Server Side Hooks for our hosted Git and Subversion repositories. Today we present to you our first Community Contest - write Server Side Hooks to get Assembla for free.

What can You do with Server Side Hooks?

Anything. Automate your workflow - reject commits that you don’t like (no commit message? tests do not pass? does not comply with a coding standard?), trigger events on external services, rename branches... You know, it's software, anything is possible.

People have submitted two hooks so far:

  • A Subversion hook that validates php syntax. Install it and never see anyone committing non-working code again. Thanks Jakub!

  • A Git hook that validates the commit message based on a regex and rejects if it matches. It defaults to looking for “wip” in the message - any commit message containing text “wip” will not be accepted to the repository. Thanks Ido!

This is just the tip of an iceberg of what is possible. Go crazy!

How to participate

  1. Submit a server side hook for Git or Subversion via Merge Request to our hoook repository.
  2. Tweet it out - don’t forget to include @assembla and #serversidehooks
  3. When your hook is accepted and merged by our team, you win 25 Assembla subscription dollars, and your entered to win amazon gift cards that will be given out at random to participants.
  4. Submit as many hooks as you want.
  5. The Subversion and Git hook that is most installed in Commercial spaces at the end of the contest wins an additional 250 Assembla subscription dollars.

As more people submit hooks, we will unlock more prizes.

Submission and Review

Get submissions in by July 31, 2013 to be considered for the contest. We will make our final determination of winners on August 31, 2013. 

Read more about submitting hooks (and our review policy) on the hoook wiki. Refer to this list to see all the participants.

Have fun and good luck automating your workflows!

Need help?

Have questions? Contact us on our dev group.

5 Comments Click here to read comments

Personal Github Mirroring in 3 Steps

Posted by Michael Chletsos on Thu, Jun 27, 2013
  
  
Tags: ,

Github Repository Backup

Github is a great service and very reliable, but your code is so precious you back it up in several places just in case it is unavailable when you need it most. Occasionally, Github does go down, it’s a fact of life. With Github having 99.69% uptime over the past year, that means about 27 hours a year your code is unavailable. It is time to get that code elsewhere, so you can continue working without any hiccups. An easy way to always be moving forward and collaborating while Github is getting back up and running is to use a free Assembla repo as a mirror.

A mirror is a duplicate of your work. It is a point in time, just as most backups are not real-time, the mirror must be pushed to in order to get back in sync.  If you end up pushing data directly to an Assembla mirror while Github is unavailable, you will have to sync (push) that data back to Github once it becomes available again.  The mirror is just another fork of your data, that must be maintained and updated regularly.  

To setup a mirror from a local repo, all you have to do is add a remote to your git repo and then push to it with the --mirror flag. By using the --mirror flag in your push, all references and branches are pushed, it’s a complete backup. Any Assembla repo will work without any special setup, using an empty repo tool is easiest.

Remember, you will control when the mirror is updated, so you must push to this new remote each time you want to sync from your local repo to your mirror and push to your Github repository as well. I will show you how to make a nice trick for this as well at the end.

Steps:

1. Clone your Github repo locally

# git clone git@github.com:<GITHUB_USERNAME>/<GITHUB_REPONAME>.git
# cd <GITHUB_REPONAME>

2. Add the remote Assembla repo to your local Git repo

# git remote add assembla_mirror git@git.assembla.com:<ASSEMBLA_REPONAME>.git

3. Push to your Assembla mirror repo

# git push --mirror assembla_mirror 

github mirror

Now you can view your mirror in the online repo browser or pull and push to the remote mirror as necessary from your favorite client.

Remote Push Trick:

Let’s say you want to always push to both remotes, your Github and your Assembla remote, at the same time.  You can do this with a quick change to your .git/config file.  Just create a section like this:

[remote “all”]
        url = git@github.com:mpchlets/michaelspace.git
        url = git@git.assembla.com:michaels_github_mirror.git

Now you can just push like this and keep everything up to date:

# git push all

Notes to Remember:

  • This is a mirror of your local repository to Assembla, ensure that your local repository is up to date before pushing up to Assembla.
  • This is an asynchronous mirror, you must push up to Assembla to get the data there.
  • If there is a conflict, you must resolve it before the push will be successful. hint: checkout the remote Assembla repository and update as necessary or just remove and add a new one.
  • If you push to your Assembla repository, you must remember to update your Github repository.
  • Using --mirror pushes all refs and branches up to the repository, you can push just a branch without --mirror and adding the ref to the end of the command
  • Only your repository will be available in Assembla, not your Github discussions, wiki nor other features of Github will be available.

 

Get Started with a Free Hosted Git Repo from the Assembla plans page.


0 Comments Click here to read comments

Looking for a Git Bug Tracker? Look No More.

Posted by Titas Norkunas on Mon, May 20, 2013
  
  

Integrated Git issue tracker

Forget about setting up a Git repository and an issue tracker locally only to have an integrated Git repository with a bug tracking system to run your software project.

With Assembla, you have an integrated system at your fingertips - just install a Tickets tool and a Git tool to your Space - that’s it, you are done setting up, let the work begin. Out of the box, you will be able to reference tickets from your commit messages - just write “re #1” in your commit message and a link to the commit will appear on ticket #1.

Git bugtracker - integrated repositories and issue tracking

  • Change ticket statuses - just naming a ticket status - “Fixed #1” - will place a link in the ticket to the commit and change the ticket status to Fixed.
  • Track time - enter a record of how much time you spent working on a particular task by using  “Fixed #1 Time: 1h30min” to your commit message.

Want more integration?

Are people making commits to the repository, which you can’t trace back? Well, we have a solution for you. With our new custom server side hooks feature you don’t need to ask everyone to create a pre-commit hook on their machine. Just install a server side hook to your repository to reject the commits that do not contain a ticket reference - nobody will be able to push a new commit that is not related to a particular ticket.
Server side hooks to integrate git bugtracker and repository

Even more integration?

Need more automation in your workflow? You can write your own server-side hooks, which we will review and put on our servers for you to install. Just send us a merge request!

Get your free Git repository with an issue tracker here.

1 Comments Click here to read comments

Server Side Hooks on a SaaS repository? ✓

Posted by Michael Chletsos on Tue, May 07, 2013
  
  

Oh BTW, you can have Server Side Hooks in a SaaS Repository.

Cloud repository hosts have failed us. The power of hosting your repository locally is the ability to implement Server Side Hooks. These hooks allow you to control your repository and the source code contained within.  Its super convenient for an organization with many contributors to a single repository. You can syntax check code, ensure commit messages are proper, add the power of automation or anything else you need your repository to do better than if you were relying on external webhooks.

To add a Server Side Hook in your current Assembla Repository - go to the Settings Page -> Server-Side Hooks:

server side hooks

  • Git: pre-receive, post-receive and update hooks

  • SVN: pre-commit, post-commit, pre-revprop-change and post-revprop-change hooks

  • Community Supported: Submit your own hooks or partake in the fruits of another’s labor

  • Prevent commits that do not comply with your Coding Standards

  • Validate commit messages for status updates and valid ticket reference

  • Create Workflows with specific status and ticket changes or kick off external procs

We are very excited about Server Side Hooks and hope that you find them as useful as we do. Take a look at some of our other available Repository Features.

0 Comments Click here to read comments

Mandatory Code Review for Protected Branches

Posted by Sergiy Golub on Tue, Apr 09, 2013
  
  

Assembla Merge Requests adds a great value to code development process. Now it’s time to bring some more automation to the Code Review process. And here comes a new version of Protected Branches for GIT.

Old Flow

Previously, a feature development or a bugfix looked like:

  • Create a new feature branch based on current production master
  • Do some development and push code to new feature branch
  • Go to Merge Requests Tab and create a Merge Request from new feature branch to master branch

New Flow

Now, we have  Protected Branches, where ‘master’ branch is protected by your Tech Leads, it looks as follows:

  • No need to create a new feature branch, do development on master.
  • Push code to origin master

What is going to happen behind the scenes when you push:

  • A new temporary remote branch with ‘assembla-’ prefix will be created and your commits will be pushed to that branch, remote master will stay the same.
describe the image
  • A new merge request from this temporary branch to master will be created, you will see URL to MR in command line
merge request index resized 600

This occurs in 2 cases:

  • When you are a developer without write permission to ‘master’.
  • When ‘Mandatory review’ checkbox is checked for ‘master’. In this case, all pushed code will go through review process, no matter if pusher has write permission or not.
protection settings resized 600

To continue development on new automatic branch:

$ git fetch origin
$ git checkout assembla_1e65051188
$ echo “Hey, Merge Request Boss!” > WeContinueDevelopment # modify some file
$ git commit -a -m “We continue development to create new MR version”
$ git push origin assembla_1e65051188

We hope, you will enjoy the New Flow. To learn more about Assembla features or Sign Up for a Trial, click here.

1 Comments Click here to read comments

Develop Faster: Set Up Your Git Fork and Merge Network

Posted by Michael Chletsos on Mon, Mar 25, 2013
  
  

A Complete Guide to Setting Up and Working with a Git Forked Network

fork merge smI have spoken often about the Assembla process that we have been working in and how well it works for us, but how can you get the same benefits for your project? Well, there is no secret, its just a matter of setting up a development fork and merge network. The basic idea is to isolate development work from stable work. By isolating, all development work from stable work you have a clear path from developer to production. Although this process is not specific to Assembla, lets see how this will would work utilizing Assembla. One could tailor this process to work in any system, and it would be just as powerful, though not as convenient as with the tools Assembla provides.


  • Setup Development Space

First we need to setup a new space. You can do this from your Assembla start page by clicking the 'Create New Space' button. Depending on your account and plan, you might want to setup a public or private space. It does not matter which type of space you setup.

Create Space

 

  • Setup Origin Git Tool

Great, we now have a place to work within. We need to have a Git Tool, if your space configuration did not have a Git Tool, please add it from Admin tab and then the Tools Heading.

git description

Whether you just created a tool, or it came pre-configured, I highly suggest renaming the Git Tool by going to the Setting subtab. Here you can rename the repository to “origin” and set an extension if you like, for the origin repo, I do not like adding an extension – I like the origin named “project.git”. I like calling it “origin” since this is standard git terminology for the original point of the code.

rename

 

  • Initial Commit to Origin

Now we have a Git Tool renamed to “origin” but no code in it. At this point, we can push code up to this remote repository and utilize it like we would normally utilize a git repo. Just to ensure everything is working, let's make sure we can read and write to the repo. Before you proceed ensure that you have added your public ssh key to your profile (found in the upper-right dropdown menu->Edit Profile->SSH Keys). Once your key is added, follow these instructions (replacing project.git with you appropriate project name) on your localhost to create a local repository that you will sync to the remote repository:


 $ git clone git@git.assembla.com:project.git # will complain that you cloned 
an empty repo
$ cd project
$ echo “Project Readme File” > Readme
$ git add Readme # add Readme file to git tracking
$ git commit -m “Initial commit of Readme file” Readme
$ git push origin master # create a master branch in “origin” repo

 

We have just made our first commit to origin/master. If you prefer you could use the http(s) method to interact with your git repo. Https is particularly useful behind a firewall that does not have port 22 open for ssh (many corporate firewalls are setup this way), while still encrypting your data. Http(s) will have more overhead and therefore slower than the ssh protocol. It does not update your localhost with information as often as the ssh protocol (sometimes it looks like it is hanging when it is working) because it waits between actions before responding to your client.

first commit

You can view this file that was just created in your code browser by navigating back to your Git Tool in Assembla and using the Browse Code subtab. To see the actual commit, take a look at the Commits subtab.

Hint: When committing add status updates such as fixed #123 or re #123 to reference the ticket in your commit message and to post a link and commit message on the ticket.

 

  • Our First Developer Fork

Theory: One could just work in the origin repository. You can branch and commit to origin like you would any other repository, however, this can cause bottlenecks and problems for your development process. Say that developerA commits bad code to origin/master – they discover this through QA, UAT or CI, and developerB needs to perform a critical hotfix to Production. If all are committing to origin/master and deploying this to Production, then we have a bottleneck caused by developerA's bad commit. This commit must be reverted or possibly you could branch before the commit add developerB's commit to this branch, then deploy out to Production this branch. Ugh, that is dirty.

Another model may use release branches to help solve this. Release branches rely on the fact that no-one alters them between releases but takes overhead to cut them, coordinate developers and manage them. This becomes very hard to maintain across many, many developers and does not allow a free-flow of code from developer to Production, instead you must commit to several branches to ensure that you keep your Development branches and Release branches in sync. Often release branches become divergent from Development branches and you cannot patch them easily as there are different codebases and the merge results in conflicts or there is logic missing that is expected.

Instead, we introduce the Developer Fork. The Developer Fork is a repository that is based on origin, but allows the developer to maintain their own repository including branches, tags and commits. It also has one other nice advantage that is a little hard to see at first, but if managed properly, you will not run into strange merge problems with new work – all new work is applied on top of branches that are consistent with your current work. In other words, you will not get any of those annoying, you must merge before you can push errors.

To create the developer fork, go to your origin's Git Tool and then the Fork Network subtab, from here you can choose to fork your project. It does not matter if you do it to another space or within the same space. The considerations made to whether you will fork in the same space or to another space have to do with whether this is a new project being branched, if the developers will work off the same list of tickets, and if you have creation permissions in the space to create this fork amongst many other considerations. For our purposes and the purposes of most teams working on the same list of tickets, it is best to keep this fork in the same space – so that you can reference the tickets in the commits easily.

fork subtab

Once you have forked the repository go to the new Git Tool and rename it and give it an extension that matches the name in the Settings subtab. This will make it easier to talk about and remember where you are pushing code or merging to/from. For our purposes we will call it “fork”.

Advanced: Anytime you clone a repo, you are in fact creating a fork. You can then push this cloned repository to any remote repository. You may also connect any existing repository to any remote allowing you to maintain several remote repositories in a forked network in one local repo, you do not need to create a new tool or new space. If you already have two Git Tools in your Assembla space, you can add a “fork” from one repository to the other repository. Branches in git do not have to have a common ancestor nor do they even have to be related to each other; you can store completely different information in the same repository in different branches for git. So taking our origin/master setup in our space and a new Git Tool called “fork” and with the “fork” extension, we can clone this repository and then push a fork from origin back up to it. There are at least two ways to do it, each with different advantages:


 # Using “origin” repository as your remote origin for your local repository – 
typical for people who have read/write to origin/master
$ git clone git@git.assembla.com:project.git # should have Readme file from before
$ cd project
$ git remote add project_fork git@git.assembla.com:project.fork.git # add remote
for “fork”
$ git push project_fork master # create a master branch in the “fork” repo

# Using your “fork” repository as your remote origin for your local repository –
typical for developer setup
$ git clone git@git.assembla.com:project.fork.git # will complain of cloning
an empty repo
$ cd project.fork
$ git remote add project_origin git@git.assembla.com:project.git # add remote for
“origin”
$ git checkout -b orig_master –track project_origin/master # switch to local
branch “orig_master” and track the origin/master remote repo
$ git push origin master # push the orig_master branch to the “fork” remote
(origin of this repo)

  • Other Developer Forks

You can repeat the process above as many times as you like. I prefer to do this on a per developer basis. But you can easily setup a team that works in branches and has a common fork/master. This is the fork per team methodology. The advantage here is you have a single point of control for batching releases per team. However this same advantage is also a disadvantage where you have a bottleneck if a developer has committed code that is not clean or is waiting on other code.

Theory: The advantage of the fork per developer is that each developer is responsible for their own fork/master, and if they commit bad code or are waiting on other code, they do not block any other developer. This allows releases to occur more often on a per developer basis. If you are not in an environment that can sustain many releases very often, then you would arrange the fork network a little differently. Instead of developers working in the fork of origin, they will work in a fork of the fork – yes a fork of the fork. Just make the fork from the fork of origin, and you will have a repository that can merge easily back to the first level fork (use the fork network for this and just fork from the team fork to create a developers fork that will merge back into the team fork).

 

  • Branching in Forks

Theory: In general it is good to create a new branch for all isolated work, i.e. each ticket that you work on should be in its own branch. This allows a developer to start and stop work, or wait while work is reviewed or QA'ed, but still moving forward with other work.

When working on ticket branches, which I like to call ticket_X where X is the ticket number, are disposable branches. Assembla has created a convenient way of maintaining disposable branches, in your Git Tool Settings subtab, you will see a section that allows you to denote the pattern for naming disposable branches.

disposable

Then when you Merge or Ignore a Merge Request that is based on this branch, the branch is automatically deleted from the repository – truly helps with keeping a clean Development Fork. It is important to understand that even if a branch is deleted, no code is lost, that is the beauty of git, all commits are still present and the branch can be recovered if necessary. Typically, the developer will also have these branches locally still and can push them back up.

delete disposable

 

  • Merging

Theory: The general rule of merging is that you only want to merge from where you branched or to where you branched. If you jump across branches, the merging will work, but it might have seemingly strange results or may affect files that you did not mean to affect. So merge from your fork/branch to your fork/master and from your fork/master to your origin/master but not from your fork/branch to origin/master. That is a simplistic view – I am assuming that fork/branch is always coming from fork/master – but this does not have to be true. And moreover, it will not be true when hotfixes are done.

When merging from a fork upstream to your origin or from a 2nd level fork upstream to the 1st level fork (fork per team), you can create a Merge Request from the Submit Code tab, choosing your fork/branch as the Source (“From”) and the fork/master as your Target (“To”).

merge create

 

  • Code Review

Theory: All code going into your fork/master should be Production-ready code. To ensure this, most teams will need a code review process. The Code Review process in Assembla can be accomplished in the Changeset view, which you can find from the Commits subtab where a reviewer can add comments directly in-line with the code, but more appropriate it can be done from the Merge Request subtab where you will submit a Merge Request from your branch to your master. You will choose your fork/ticket_X branch as the source and fork/master as your target. Then you will set a title and description and have the opportunity to review the new code that is potentially being merged to your fork/master. This is a good time to review that the code is as you expect it, this will prevent any gotchas later.

Hint: Add ticket status updates in your description with the same format that you can use when committing to your repo, i.e. fixed #123 or fixed #tickets to affect all associated tickets, to apply this status update once your Merge Request is Merged. 

Once the Merge Request is created from your fork/branch to your fork/master you will have an interface where the team can have a discussion, including the ability to leave @mentions to alert others to help with code review, a list of the changesets that will be merged, diffs on the files that are changed, and a list of tickets (based on commit messages that include #ticket_num) that are being affected by this Merge Request, in-line code commenting, and of course a place to vote on the Merge Request. If you give it a -1 vote, the system does require you to submit a comment, this is because it is typically not beneficial to just leave a -1 without any comment – whereas a +1 speaks for itself (I highly suggest leaving comments on what is proper in the code with a +1).   

merge request

Hint: Setup your CI server to automatically submit votes to your merge requests utilizing the API and/or JAMRb to run Jenkins builds off of your Merge Request. Authenticate with the Assembla Jenkins Auth Plugin.

If the Merge Request is merged via the “Merge and Close” button, the system will automatically merge to the target repository and the disposable branch will be deleted (if applicable). If Ignored, the disposable branch will be deleted and the Merge Request will be archived.

 

  • Deploying

Deploys should always run from origin/master unless you are doing some creative deploying where you want to test out branches in Production before merging them into origin/master (this is a highly advanced workflow and typically needs a level of coordination and architecture that most projects do not have nor can sustain as they grow). This means that origin/master should always be deployable and developers can trust that if they fork/branch or merge from origin/master it has good, Production-ready code.

 

  • Hotfixes

I mentioned that hotfixes are a bit different from regular merging workflow, well it can be true if you need to make a critical patch immediately. In this case its best to work from a branch of origin/master, even if you only have read access from origin/master this can be accomplished, since it is guaranteed to be in sync with your current Production if you always deploy origin/master. Once you have your fix in your local branch, you can push it up to your fork as a branch and create a Merge Request from fork/hotfix_X to origin/master; since you branched from origin/master you should merge directly back to it. To see how this would work in a developer fork with a remote of origin/master called orig_project and a local branch of orig_master tracking origin/master:


 $ git checkout orig_master # checkout the origin/master tracking branch on a 
remote called orig_project (not the origin of the local repository)
$ git pull # make sure it is up to date
$ git branch hotfix_ticketNum # create new branch locally
$ git push origin hotfix_ticketNum # push hotfix_ticketNum branch up to fork
remote (called origin locally)

 

Now you can create a Merge Request from fork/hotfix_ticketNum to origin/master and have Code Review before merging and then deploy to Production.

 

  • Conclusion

So that is basically how you set up a fork network in git for developers to be able to isolate their work and merge back to origin/master and from origin/master to their development fork.

To Learn more about other workflows, click here.

2 Comments Click here to read comments

Put Down Your Forks - Introducing Protected Branches

Posted by Titas Norkunas on Thu, Mar 21, 2013
  
  
Lets talk about forks. They are so awesome for open source. Why?
  • A fork is a natural way to give external contributors a place to work
  • Really, that is the main reason to fork
Look at the open source projects more closely. Only the external contributors - who are not part of the core team - work in forks. The core team members work with the main repository in branches.

A company does allow their developers to commit to the repository. A company does not want everyone to be able to merge to a release or master branch, using a fork for this is an over-complicated workaround:
  • Developers need to maintain forks
  • Additional setup to CI is required
  • Whenever a change to the repository configuration is made, it needs to be made in all forks (for instance installing a webhook)

Does it have to be so difficult? Not at all. Here is where Protected Branches are awesome and a clean solution to this problem.

A Protected Branch is a branch with limited write access. Specify members (or groups) of your team that will be able to submit code to a branch:

Protected Branches

Now, only these people will be able to push to the Master branch. Everyone else will have to contribute code through merge requests. They will be able to push to any other branch in the repo, but not Master.

Protected Branch

Protected Branches enable various common techniques - mandatory review from a senior developer, release manager that maintains release branches, feature freeze a release candidate. We have no doubt you will find even more use for it.

Sometimes you just have to leave that Social Coding aside and get some work done.

5 Comments Click here to read comments

All Posts | Next Page

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: