Hi guys! I'm new to git so this is something that keeps concerning me till now ...
As you guys already knew, below is the most popular git flow. But to me sometimes, I did have some problem with creating new feature branch from develop branch. Because if someone before me, who already committed and merged something bad into develop branch and after that, without knowing I create a new branch base on it, then I will work on a branch with potentially broken, right ?
Then in my new team, I saw a git flow like this:
Every feature branch is created from master
When a feature is complete it is merged into the develop branch (testing env)
If tester sees there's no problem with develop branch then:
A release branch is created from master
Merge all the completed feature into the release branch. (and test 1 more time on STG env)
No need to merge back release branch into develop branch. If there's any problem, fix it on feature branch and merge it into develop branch (test again) and if it's ok, merge it into release branch.
Merge release branch into master.
Doing it this way ensures that every time a new feature branch creates, it have already gone through 2 phase of testing or so I think...
Please give me advice on this one, is it good or not ? Or is there any disadvantage that I dont know. My new team has been working on this git flow for few years and there's no problem until now. But when I suggest it to my friend, they don't like the idea saying that I should have followed the popular one... I'm kinda confused right now. Thank you very much.
First of all, git-flow is just a framework. There is no reason why you should not adjust it to your needs.
But there are some disadvantages in creating branches that way:
(1) Your testers might (and most certainly will at some point) still miss a bug which then will end up on master. We are all humans and it's simply impossible - no matter how many testers and test phases you have - to produce software that is completely bug-free. master is just your new develop.
(2) The more important issue here: you always have to wait until new features are on master to continue working on them. Often bigger features are split into multiple issue / user stories / whatever to make them easier to work on. You would normally merge part 1 into develop (considering it's a shippable feature in itself) and then continue working on this using develop as your base.
This is going to be hard (meaning delayed using your master-base method).
Related
We have 2 features A and B already merged into dev branch, branch dev using for test environment and both 2 features are tested. Now we just want to release only feature A, how to do it ? Did our git flow is wroong ?
Your git-flow looks fine so far. It is simply not meant to be used to release develop partially.
Whatever gets merged onto develop is meant to be released.
Here are some solutions you could use:
(1) Do not merge (or better don't even start working on it) a feature until you want to release it.
(2) If you want to merge unfinished features add a feature toggle to easily turn on and off whatever is on develop.
Heads-up: not everyone thinks this is good software design - me included. But for the sake of completeness I wanted to mention it.
(3) Also not a good approach but technically possible: Revert the features you don't want to release on your release branch. This might be your only option now if you don't want to re-write the commit history (which you should not).
(4) Create a new release branch starting at the commit just before feature B was merged in and cherry-pick feature A into that release branch.
I am writing an application that automates the re-building of a branch based on a new head. It uses cherry-picking to get the job done, but many times the app runs into merge commits that have 2 parents. When I do:
_ngit.CherryPick().Include(commit).Call();
...it throws an exception, Cannot cherry-pick commit '{commit_id}' because it has 2 parents, only commits with exactly one parent are supported.
I need the ability to cherry-pick these merge commits, selecting the first parent as the base. Seems like there would be something like:
_ngit.CherryPick().Include(commit).WithBase(0).Call(); (where 0 is the index of the first parent that I want to use as a base)
I've seen various hints on the web where people trying to get this ability added to jgit, but I've never seen any documentation or anything in the API that suggests it's available. Some such "hints" are:
Patch to egit in 2011
Another patch in 2011 that looks like it made it into egit, but not sure jgit
Patch to jgit in 2012
If this is possible with jgit, please tell me how. If there's another way to get these merge commits added into my new branch, I'm all ears.
I am new to Plone and trying to learn how to setup and maintain a server. I realize I need to develop a schedule for packing the data. Right now I am just trying to test this using the pack function in the Zope control panel and also the command line (bin/zeopack).
I know in practice I should leave a week's worth of history, but if I pack to 0 days shouldn't I see all edit history disappear? I am not seeing this happen. What am I doing wrong?
You may be confusing the "undo" history with the version history. Packing the database gets rid of old, unused data. That eliminates your ability to undo older transactions.
Version history is not the same. Version history is not considered unused data, and is not eliminated in packs.
If you don't want edit history, turn off versioning.
My team now has an SVN + Ankh setup in ASP.NET with trunk, branches, and tags. We switch branches and work on code, but many times there will be inexplicable conflicts in files after simple changes. Why is this? I suspect we simply don't understand enough of how this works. Are there any do's and don'ts, or how should we be approaching our daily changes and commits, without causing conflicts? Is there a basic pecking order of operations to perform to achieve SVN zen? Are we updating before committing or something? Any help is greatly appreciated.
Always update before commit. If you really work with branches don't use switch or only if you really undstand the switch command and how it works otherwise checkout a branch into a fresh working copy in other words create a new one.
Always branch, merge on the solution element, make sure you're fully up to date before merging (ankhsvn will warn about this), also make sure you have no modified files before merging.
Read up on svnbook for when to use normal merging and when to use reintegrate.
Finally, if a conflict does occur, make sure you have a good 3way merge tool to solve the conflict. AnkhSVN recognizes a lot of them automatically, but I really like source gear diffmerge
I've just started working in a continuous integration environment (TeamCity). I understand the basic idea of not getting so abstracted out in your code that you are never able to build it to test functionality, etc. However, when there is deep coding going on, occasionally it will take me several days to get buildable code--but in the interim other team members may need to see my code.
If I check the code in, it breaks the build. However, if I don't check it in, my team members are unable to see the most recent work. I'm wondering how this situation is best dealt with.
A tool like Code Collaborator (Google link, smartbear.com is down..) would allow your peers to see your code, without you committing it. Instead, you just submit it for review.
It's a little extra trouble for them to run it though.
Alternatively, setup a second branch/fork of your codebase for you to work in, your peers can sync to that, and it won't break the build server. When you're done working in your own branch, you can merge it back with mainline/trunk/whatever.
In a team environment, it is usually highly undesirable for anybody to be in an unbuildable state for days. I try to break large code deliveries to as many buildable check-ins as I can. At minimum, create and check in your interfaces even if you do not have the implementation ready so others can start to code against them.
One of the primary benefits of Continuous Integration is that it shows you when things break and when things are fixed. If you commit those pieces of code that break the system, other developers will be forced to get it into a working state before continuing the development. This is a good thing because it doesn't allow code changes to be made on top of broken things (which could cause issues where a co-workers code worked on the broken system, but doesn't work once the initial break is fixed).
This is also a prime example of a good time to use branches/forks, and simply merge to the trunk when all the broken things are fixed.
I am in exactly the same situation here.. As build engineer I have this working beautifully.
First of all, let me break down the branches / projects. #Dolph Mathews has already mentioned branching and tbh, that is an essential part of getting your setup to work.
Take the main code base and integrate it into several personal or "smaller" team branches. i.e. branch_team_a, branch_team_b, branch_team_c
Then set up teamcity to build against these branches under different project headings. So you will eventually have the following: Project Main, Project Team A, Project Team B, Project Team C
Thirdly, then setup developer checkins so that they run pre-commits builds for the broken down branches.. You can find the TC plugin for this under tools and settings.. They have it for IntelliJ or VS.
You now have your 3-tier setup..
- Developer kick starts a remote-run pre-commit build from their desktop against their project. If it passes, it get's checked into the repository i.e. branch_team_a
- Project Team A passes after several check-ins; at which point you integrate your changes from branch_team_A to main branch
- Project Main builds!
If all is successful then you have a candidate release.. If one part fails, projects a, b or c. it doesn't get checked into main. This has been my tried and tested method and works everytime. It also vastly improves team communication.