Git (DVCS) Workflows for LabVIEW

[GregFreeman]

Hey everyone, I was just curious how many of you are using Git and what workflows you have found to work well with git and LabVIEW? Do you use the same workflow no matter the project, or the stage in the project? What about depending on the number of developers. I'm just looking for what others have found to be successful so I can avoid reinventing the wheel. This doesn't have to be only with relation to Git, but I'm assuming a workflow with regards to Mercurial will still translate relatively nicely. So, more generally, I suppose this question has to do with DVCS workflows.  I know there are lists of them out there but I want to know what you, the LabVIEW developer, finds to work best. Feel free to add into the workflow github and bitbucket tidbits, since I am playing around with both of these to host the repositories as well.

Edited November 21, 2013 by for(imstuck)

[PaulL]

I've been using the Atlassian SourceTree client (free; Windows and Mac--no Linux support at this time) and the more I use it, the more I like it.  (The use of the Pageant client is a bit clunky, but not really a problem.)

Anyway, Atlassian's Git Tutorials are quite good, and include some helpful sections on workflows.  I was quite impressed with the Gitflow Workflow section, and I hope to implement that approach (I haven't gotten that far just yet) in the near future.  This workflow seems to be a logical, manageable, and consistent approach to handling development in branches and versioning (and seems to be applicable to LabVIEW, with the caveat that I recommend avoiding merging in LabVIEW with the present tools*).  I highly recommend taking a look at that.  I would include the links if I could, but since those are disabled at the moment, you will have to do a search.  I'd like to know what you think of it.

 

*I think the merge functionality itself is pretty good, but the API--how it links to the version control provider--is lacking, in that it doesn't cover some very common use cases (I've written an ad hoc wrapper to trick it), and in that it can take a very long time to load the appropriate files sometimes.  My guess is that it wouldn't require all that much additional effort to make this a really useful tool (I think what is there is really pretty cool!), but with the current interface, it is rather useless in practice, and I can't remember ever using it to accomplish any meaningful merge task. I'm glad it exists, but I wish it would do more.  Comments on this, LAVA folks?  Does anyone merge LabVIEW code routinely?

Edited November 22, 2013 by PaulL

[GregFreeman]

I've been using the Atlassian SourceTree client (free; Windows and Mac--no Linux support at this time) and the more I use it, the more I like it.  (The use of the Pageant client is a bit clunky, but not really a problem.)

Anyway, Atlassian's Git Tutorials are quite good, and include some helpful sections on workflows.  I was quite impressed with the Gitflow Workflow section, and I hope to implement that approach (I haven't gotten that far just yet) in the near future.  This workflow seems to be a logical, manageable, and consistent approach to handling development in branches and versioning (and seems to be applicable to LabVIEW, with the caveat that I recommend avoiding merging in LabVIEW with the present tools*).  I highly recommend taking a look at that.  I would include the links if I could, but since those are disabled at the moment, you will have to do a search.  I'd like to know what you think of it.

 

*I think the merge functionality itself is pretty good, but the API--how it links to the version control provider--is lacking, in that it doesn't cover some very common use cases (I've written an ad hoc wrapper to trick it), and in that it can take a very long time to load the appropriate files sometimes.  My guess is that it wouldn't require all that much additional effort to make this a really useful tool (I think what is there is really pretty cool!), but with the current interface, it is rather useless in practice, and I can't remember ever using it to accomplish any meaningful merge task. I'm glad it exists, but I wish it would do more.  Comments on this, LAVA folks?  Does anyone merge LabVIEW code routinely?

 

So, I have been using the same tools, and pushing everything out to bitbucket. Are you doing the same? I will outline the workflow I have been following (essentially the gitflow built in to SourceTree), which may be complete overkill for small projects, but I also think it will work well for large projects. That said, I am debating with myself on the workflow between the following two things: ease of use for a particular project vs using a familiar workflow for all projects. If you use the same workflow for everything, it can be total overkill when you have a project that has a single developer. Yet, it can be more inefficient because you need to use a different workflow than you are used to using on larger projects. So, to be honest, right now I'm "playing" with each one to see how difficult it is to transition.

 

So, because I am using bitbucket, my current workflow is as follows:

1) Every developer forks the main repo on bitbucket

2) In SourceTree, every developer adds two remotes: First is the upstream pointing at the main repo, second is the origin, pointing at their forked repo. (there is some debate out there as to which should be named which, but I am ignoring those things for now)

3) Each user clones the upstream repo giving them a "master" branch and a "develop" branch. 

4) Set the local develop to track the master develop. 

 

Now, if any changes by other developers are pulled into the master develop, I will see I am behind locally. I then pull in those changes, merge with my local code, then push to my "origin" out on my forked remote in the cloud. When I am ready to add any changes I have made, I merge that feature branch into my develop. I push the develop to the origin (i.e. my fork in the cloud). From there I create a pull request, and pull everything into the master. The cycle then repeats itself. 

 

I do like the fork, because I can push my code to my origin and manage stuff there, without pushing it all to the master repo. Then, if I am working on a feature with others, they can pull those feature branches from my fork, but those features aren't out in the master repo.

 

I also like the idea of pull requests because what I'm hoping to enforce is someone minimally involved in a project will be the main repo manager. The pull requests then force code reviews and discussion before anything is merged. This may be too big a bottle neck, but we will see. I like the idea of developers developing, and not dealing with repo management, and this helps that. 

 

Now, this all seems great in my head, but I haven't tested it much, so I have to put that disclaimer in here. I also haven't had to do any nightmare diffs and merges when there are conflicts, so we'll see how that goes. I think breaking tasks and features up into small chunks and committing early and committing often will help resolve some of these pain points. I'll let you know how things go as I move along. It's good to know other people are using similar tools.

 

I also know this may be an opinionated subject and largely based on the types of development each of us does and the end customers we support. As such, I expect there to be different methods and work flows that all ensure equal success, so I think it's best to have as many outlined as possible allowing people to pick and choose, mix and match as they see fit.

 

Edited for minor grammatical errors...

Edited November 25, 2013 by for(imstuck)

[PaulL]

Well, we are at the moment using a local server as the central repository, not Bitbucket.  I think I favor the Gitflow workflow over a Forking Workflow for our purposes, but for your purposes you may find the opposite (and you have actually tried it, while I haven't yet!).

 

I completely agree that "breaking tasks and features up into small chunks and committing often will help resolve some of these pain points."  I think that careful planning can remove (completely?) the need for merge operations (when merging a branch to the trunk, for example) to merge code within files.  (Hopefully merging will just add/delete/replace files.)

[GregFreeman]

Can I ask how big your development team(s) is/are? 

[PaulL]

Small (on the order of 3 to 6).  Yours are larger?

 

I find it important (for many reasons!) to follow an iterative process, involving daily stand-up meetings.  If the team members know and agree on the focus of each team member every day, it makes it much easier to avoid stepping on each other's toes.

[GregFreeman]

Ours are the same size. Six would be a relatively big team in fact. We usually have developers come on and off projects throughout their life cycle as they get interrupted by support for other projects etc.

 

I completely agree and we have been starting to do daily standups. We have one person we are managing offsite for one particular project, so we're really throwing ourselves in the deep end with this one! I'll do my best to keep this thread updated as we learn from our mistakes so others can try to avoid them in the future.

 

I have yet to set up LabVIEW Compare and what not, which I need to hack my way through this week. I found something on github that is supposed to help with this https://github.com/joerg/LabViewGitEnv so that is my next step. We'll see if I can manage.

Edited November 26, 2013 by for(imstuck)