|
Down is not the problem. 
|
|
|
|
|
Hi everybody, me and my coworkers are new in Git, we just come from TFS, no one in the company had used Git before, we are totally noobs with Git.
So here comes our big question...
We don't know and it's not clear in the documentations (mostlry based on this http://nvie.com/posts/a-successful-git-branching-model/[^])
if:
- When Release-XX is in QA, should Development be in Code Freeze, no new Features are added or bug fixings that doesn't comes from Release-XX?
- Are we able to add or features after we end (following Pull request) or all the Pull request should be approved at the end some days before the new Release will be created?
I personally believe Development is for Developers, so its free, if I finish a feature or bug it should go to Develop branch, without being queue for weeks, this avoids the chaos or merging all the Features in the same day. But we are doing Code Freeze in develop when there is a Release-XX branch in QA, and due there is always a Release-XX, I can't never Finish my Ticket until the Pull Request fails due other Pull request approvals, then I must re-do my Pull Request.
If someone can give a good advice on how this should work, and provide links with documentation I would really appreciate it, I feel like we are in a Git-Chaos train
|
|
|
|
|
I am no guru in git (still confuses the hell out of me at times!), but I would have thought you would create a new branch to continue developing in. Alternatively clone the Repo into a whole new fork and develop on that, you could then do a pull back into the previous (in QA) repo.
|
|
|
|
|
We are using git flow.. it uses 2 main Branch:
Main <-- Current production, no one works here, you can create branches for hot fixes.
Develop <-- you get branches and do you work (Features), at the end you merge all there. When a release is planed, they get a Branch, called Release-## and that one is in QA and you can en theory continue working in Develop and the Features branch
so is like you said, but following the Git Flow logic, what we are not sure is when can we merge into Develop branch, and if we should or no do Code Freeze in Develop...
|
|
|
|
|
|
That link gave me a good clue...
When finishing a feature, it merges and deletes the local feature branch....
You can't do Develop code freeze if you applies that.. it sounds more as I like it and less as we are implementing it...
|
|
|
|
|
We have just starting using Git and it still confuses me, but once we are ready to do a release for verification and certification processes to be performed, we create another branch for development to continue and then rebase once the release is finished.
|
|
|
|
|
That is no Code Freeze over Develop... developers can close they Feature and merge in the right order. That sound good
|
|
|
|
|
I can't speak to the proper way to use Git-Flow, as I'd never heard of it before this post. However, I've been using Git professionally for about 4 years now, so maybe my experience will still be helpful.
I've found that the answer to most questions about using Git is "make a new branch".
Need a release that's "frozen" for QA? Make a new branch for it. There's no need for that to affect any other branch, since you can use cherry-pick to pull just the commit with the bug fix you need from your Dev branch to your QA branch without pulling anything else from Dev (assuming said bug fix doesn't depend on other commits). Alternatively, you can fix the bug on your QA branch and merge that change back to your Dev branch, again without pulling anything from Dev to QA.
Not sure if the thing you're working on should be in the main development branch yet? Make a new branch for it. Feature branches are fantastic, especially if you're working on a feature you aren't entirely sure how to implement. Think of it like a white board you can use to explore possible solutions, and then wipe clean if your current tack doesn't pan out. Plus, you can easily switch back to the main branch any time if, say, there's some bug you need to urgently fix.
Branching and merging are just so easy with Git that it's almost like you should branch by default unless you have some specific reason not to.
That said, I also recommend that you use rebase rather than merge. The reason is because bisect is a fantastic troubleshooting tool and it works better with a linear commit history, which rebase gives you. Some people will make a lot of noise about how merge preserves history and rebase doesn't, but that's a load of rubbish. The history that merge preserves is useless. I have never needed to know what the date was when J Random Dev originally created Commit-X, but I have many times needed to know when Commit-X was added to the branch I'm currently looking at, and rebase makes it easy to see that.
|
|
|
|
|
|
Thanks both for your answers...
I see now that probably my question was not clear enought...
Quote: I've found that the answer to most questions about using Git is "make a new branch".
That is exactly what we do... the question is, when you finish with your Feature Brach, are you able to merge it into Develop? (at this point QA have one Release XX)
That is the question, when are or aren't you allowed to merge. We are implementing Develo Code freeze until Release is close and merge, so all the pull request are applied at the end, it can be chaotic. So am I supposed to always merge after I finish into develop?
I hasn't see any single graph or draw showing Dev-Features-Release-Production-Hotfix interaction all at the same time, they are always modularized and never show the intersection between all.
|
|
|
|
|
When to merge two specific branches is a policy decision for your lead/project manager. In my case, I don't have to deal with QA, Release, or Code Freeze, but that's just a peculiarity of being a tools dev in the game industry. But, here is how I would do it if I were asked to:
Master: aka Develop. It is by and for the developers, and they control when things get merged into it. I see no reason why this branch should ever be frozen, but it should also never be broken (that's what feature branches are for). A dev should ALWAYS rebase their feature branch on master and test it before pushing to master/submitting a pull request.
Feature branches: Created and deleted by individuals/teams as needed. Merged into master when the feature is "done" (ready for validation, QA, etc).
QA/Freeze: branched off master from whatever commit is determined to be a release candidate. Bugs should be fixed on this branch and those fixes should be merged back into master asap.
Release: QA/Freeze branch when it's deemed ready to ship. The branch name should probably include the version number (eg: "release_3-0-0"). Start a new QA branch for your next RC.
Other branches (Production, Hotfix, etc) are basically just special cases of the above.
|
|
|
|
|
I've found that developers who program for fun at their off time usually more in-tune with their skills and have broader knowledge. There are developers that would code at work but have other interests out side of work tense to not very deep in their field. Is my observation off?
|
|
|
|
|
Leng Vang wrote: Is my observation off?
Yes.
|
|
|
|
|
Totally. When its your job you have to get it right, if a hobbyists programs fails what does it matter? plus if you work in a team you glean knowledge from those that know more. A hobbyists and self taught person can fall into bad habits without knowing or realising. do I need to go on lol. GL
|
|
|
|
|
I think you are missing the point - I think the question was about coders who do it for a job (and by your argument have to get it right) and also code as a hobby as well - does coding as a hobby give you a broader knowledge.
Myself, I expect (broadly speaking) coding is like anything else - the more you do it, the more practiced you get at it. It doesn't necessarily make you a better coder, it usually means you code more, and depending on what kind of coding you do as a hobby get a wider experience. Stands to reason really - chances are hobbyists aren't coding the same kind of things they would at work.
Also, chances are hobbyists are more interested in coding for its own sake and enjoy doing it, which would probably mean they learn more and have a broader knowledge.
_WinBase_ wrote: A hobbyists and self taught person can fall into bad habits without knowing or
realising.
Are non-hobbyists immune to bad habits? I don't think so somehow.
_WinBase_ wrote: do I need to go on lol
Nope. Please don't. 
|
|
|
|
|
I think we will have to agree to disagree. Ive coded for a living for a long time and still love the challenge & satisfaction of my job and still give it my all to write the best code I can. I cant speak for others, but saying stuff like 'chances are' and 'probably mean they learn more' doesn't fit with my experience at all, or of others when I used to work for companies. GL
|
|
|
|
|
|
Ahhh - the Schrodinger's Programmer Paradox.
You can't determine if a progrmmer is good or bad until you've opened his source code, but until you do, he can be both good and bad.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Leng Vang wrote: Is my observation off?
Just by responding, I could affect your observation. Ergo, no comment. But keep observing.
|
|
|
|
|
Schrödinger's answer...
Government is not reason; it is not eloquent; it is force. Like fire, it is a dangerous servant and a fearful master. ~ George Washington
|
|
|
|
|
Yes and no at the same time, until you observe.
|
|
|
|
|
quantum 
|
|
|
|
|
Leng Vang wrote: Is my observation off?
There's an absolute possibility.
New version: WinHeist Version 2.1.0 Beta
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
I'm not crazy, my reality is just different than yours!
Not my circus not my monkey's!
|
|
|
|
|
Mike Hankey wrote: Not my circus not my monkey's!
So, you do own a circus, just not the one referred to? Your monkey's what? That implies you do have a monkey (In your circus?) that is properly referenced by the question but your monkey doesn't own whatever the subject of the question is.
Sorry, but the thread itself seems a bit silly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
