CODEWITHSUNDEEP
gitversion-control
Juan Carlos Coto
Juan Carlos Coto

Reputation: 12574

What is the recommended workflow using Git?

I am trying to figure out what is the best workflow to use Git to synchronize a code base used by several developers concurrently. I have a script that was provided for me by my team leader, which adds pretty much all the code files I need to sync, leaving out batch files, compiled files, etc.

In general, what I believe I should do is sync before I start working on a problem, then sync when I am done testing. However, I am afraid this will implicate a long lapse between when I pulled the repo's code and when I publish mine. This means, for example, that I might use some functions which have been either broken or fixed without my knowledge or that I might break some code inadvertently during that lapse, which someone else was using. Also, I think publishing "unfinished" code might be a bad practice, but I'm not sure.

How can I manage my syncs so that I interfere as little as possible with others' code, and avoid a long turnaround time? Any recommendations are welcome.

Upvotes: 2

Views: 163

Answers (2)

Kamil
Kamil

Reputation: 2860

If you're looking for a workflow information check the article which is available here http://nvie.com/posts/a-successful-git-branching-model/. It describes one of the Git workflows (and nice Git plugin which helps to manage repository branches).

Upvotes: 1

count0
count0

Reputation: 2621

My strategy (there are many others) in this case would be:

1.) Create two branches for yourself, in your own repository. One with working code ready for release (YOUR release branch) and one for development/bugfixes (YOUR devel branch).

2.) In general: Your devel branch gets the latest code from source plus from your release branch. That way if there are any changes to the source, you can fetch that and are up to date. Also if there are changes from your development side, you can fetch that. (For example, you were ready to publish but just realized the source API got changed.). You'll end up with a devel branch which has your (stable) changes plus the source changes, plus (unstable) fixes you can work on.

3.) Once your ready with development, merge your fix branch into your release branch and provide your release branch code for review/integration to the lead. In case something changed meanwhile and it really needs to be fixed you'd go back to step 2.).

The idea is to have a release handy at all times but continually flow changes and fixes into it, keeping it stable and up to date while at the same time having a unstable development branch with latest code from all sources.

(project)           src-branch ----*----*---*-----*----------*------M
                                    \              \               /
(personal) devel/bugfix-branch ------M-*-*--*-------M-M---*--*----/--
                                             \       /         \ /
(personal)      release-branch ---------------M-*---*----*--*---M----

                               ------ time ----->

Legend: * commit, M merge

In the last step you'd actually provide either a git-diff patch or let the lead fetch your contribution from your release branch (of your BARE repository) for review/integration into the project source.

Upvotes: 2

Related Questions