Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have multiple projects on Git that I eventually want to bring others into. However, right now it's just me and I use Git and GitHub very simplistically: no branches and basically just using the commits as a backup to my local files. Sometimes I'll go back and look at previous versions of my files for reference, but I haven't needed to do any rollbacks to this point, though I appreciate the option should I need it in the future.

As a sole developer, what Git or GitHub features could I take advantage of that would benefit me right now? What should my workflow be like?

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

share|improve this question
add comment

3 Answers

up vote 23 down vote accepted

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

Of course. There is a simple good practice that you can use even if you don't have a team right now: create a separated branch for development. The idea is that master branch will contain only released code versions or major changes. This can be adopted easily by new developers that join your project.

Besides, branching is useful even if you are working solo. For instance, you find a bug while in the process of coding a new feature. If you don't use branches, you will have to do both: add new features and fix the bug in the same branch. This is not good :P On the other hand, if you had created a new branch for creating your new feature, you can just checkout the development branch, fix the bug, and checkout back the new feature branch.

This is just a brief example of what you can do being a sole programmer. I am sure there must be more good practices.

I highly recommend you this article: A successful Git branching model

share|improve this answer
    
+1 - That makes sense. I'll be taking a closer look at that article too, it looks very useful. –  VirtuosiMedia Oct 13 '11 at 21:39
    
I'm not a git specialist, mostly a Mercurial user. Does this dev branch advice still hold in the case of Mercurial? It looks like it does but maybe some differences makes it not a good idea in this case? –  Klaim Oct 13 '11 at 21:54
1  
Yes, it pretty much holds for all source control. I actually do it backwards with SVN; the "main" trunk is for the latest development, which goes in daily or even more often. When a release is called for, the code is frozen and a branch cut. That branch only gets minor updates to fix major release issues, and then the distributable is created from that. That way, I have a branch of the source code behind each released version. This is better than simply tagging or labeling b/c if commits come in after the label but before the release, you don't know if they were actually excluded. –  KeithS Oct 13 '11 at 22:19
    
+1 for the article; @Klaim -- yup, works great for hg too. really should be called "successful DCVS branching model" –  Wyatt Barnett Oct 13 '11 at 22:46
    
+1 thanks for the link, it changed the way I will work with git, not by much mind you but as they say, every little bit helps ! –  Newtopian Oct 14 '11 at 2:06
show 1 more comment

I'm exactly in this situation but I did opt for a slightly more complex though not necessarily more complicated workflow with Git.

The objective at first was learn the git way so I did some amount of exploring. then reverted to pretty much the workflow you described.

After a while this became difficult to work with as some situations arose also it gave me bad habits that would be hard to break once I join a team.

so I settled for the following :

  • Local repository for working.
  • Master branch as a stable trunk for the application
  • One branch for each feature / refactor, basically one branch for each sizable changes that will be done.
  • Merge back to trunk when the branch is stable and all tests pass.

I also setup a git hub account where I synchronize the trunk. This allowed me to easily start working on different computers. It was by necessity but allowed me to find bugs that were tied to the environment I was in which was not available on the other computers. So now I make it a habit to try a project on a different "virgin" system at least once. Saves me a lot of headaches when comes time to deploy to the customer.

  • I tag every versions that makes it into github as a releasable version.
  • If released to the customer I will branch from this version to create a second stable trunk for bug fixes declared by the customer.

The multiple branches at first seemed like overkill but it REALLY helped a lot. I could start an idea in a branch, work on it for a while and when I start running circles I gave up and started another branch to work on something else. Later an idea came where I would come back to the half baked branch and explore this idea. this overall made me MUCH more productive as I could act of flashes and ideas very quickly and see if it worked. The cost of switching branches with GIT is extremely low making me very nimble with my code base. That said I still have to master the rebase concept to clean up my history but since i'm all alone I doubt I really need to. Pushed it as "nice to learn".

When all the branching became complicated then I explored the log option to draw a tree of changes and see which branch are where.

Long story short, git is not like SVN, CVS or (brrr) TFS. Branching is very cheap and making mistakes that will wipe out work is actually pretty difficult. Only once did I lose some work and it was because I made my commits too big (see bad habits above). If you commit often, by small chunks git will definitively be your best ally.

To me git opened my mind to what source control really is all about. Anything else before was just attempts to get it, git is the first, that in my mind, got it. That said, I did not try other DVCS, quite possibly this statement could be widened to the whole family.

One last advice, the command line is your friend. Not to say that graphical tools are not good, quite the contrary but I really groked git when I dropped down to command line and tried it out myself. It is actually very well made, easy to follow with a very comprehensive help system. My biggest problem was being tied to the but ugly console in windows until I found alternatives.

Now I use both, Eclipse integration with Git to see what is going on in real time and do some operations like diffs, explore history for a file, etc. And command line for branching, merging, pushing, getting and the more complex log trees. some basic scripting and I've never been so productive with regards to source control and I never had so much control over my source.

Good luck, hoped this helped.

share|improve this answer
add comment

I'm well-versed in several sophisticated branching models, and use some at work. However, when I work alone on projects, I do pretty much exactly what you're doing now. I can always create a branch after the fact if I need one, but I almost never do. Working alone, I rarely have bug fixes that can't wait until my current task is finished. My advice is to be familiar with some branching models, but there's no sense complicating things until you need to.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.