I have a web project with a second developer. My part is doing the HTML+CSS+JS stuff, and my buddy writes the PHP+MySQL scripts.
So, mostly I prepare forms and the design of the page (and do the javascript stuff when needed). However, in order to work properly the other developer has to connect the forms I created with php to the database.
Is there an easier way instead of doing 2 commits (1. "html created" + push. other developer has to pull, commit "php added" and push it back)? Like passing the files to the other developer - an he just commits all files? Maybe something like doing a temporary commit, so that he can take it, modify the files, and push it all together...
I'd prefer the workflow you described since it's consistent:
Of course, you won't do all that on the master
branch. Create a devel/whateverfeature
branch, work on that, once you finished development, squash changes and merge them into master
.
I cannot see any bad things with this workflow...
However, if you absolutely don't want to see the public your development process, you could share a branch between you and your fellow. Your fellow adds your working copy as remote, you add the other working copy as remote.
Once you finished your work, tell him to fetch changes from your machine.
Once she's finished her work, she tells you to fetch changes from her machine.
You could do that either manually or by using git request-pull
.
Third option would be exchanging patches like Akash proposes in his answer. The advantage of sending patches is that neither you nor your fellow needs access to the machine of the other AND the commits never appear in the public.
But even in this case, I wouldn't create a temporary commit. Do a real one or do 10 real ones. Once you finished your work, ask git format-patch
to create the patches for you that you want to hand over to your buddy. Assuming you produces 10 commits that your peer needs,
git format-patch HEAD~10
will create 10 patch files that you could simply send over by e-mail to your fellow. The patches get applied with git am
and your colleague will have YOUR COMMITS with YOUR COMMIT MESSAGES.
If you're more interested in different ways of working with different repos, have a read of the Distributed Git section of the Git Book. This covers different scenarios how to hand over commits to each other.